fix(build): rebuild lsp_all.o when its included headers change

[KerseyFabrications]

Fixes #661

Problem

On an incremental build, make can link a stale lsp_all.o. ASan surfaces it as a stack-buffer-underflow during Rust-LSP tests:

ERROR: AddressSanitizer: stack-buffer-underflow ... in __interceptor_memcpy
  #1 cbm_calls_push internal/cbm/cbm.c:128
  #2 rust_inject_syn_call internal/cbm/lsp/rust_lsp.c:3366
  ...
  'call' (line 3363) <== Memory access at offset 0 partially underflows this variable

Root cause

lsp_all.o is a unity object that #includes every lsp/*.c resolver; those include cbm.h, and CBMCall is copied by value across the lsp→pipeline boundary (cbm_calls_push). Its Make rule depended only on lsp_all.c, not on cbm.h. After CBMCall gained bool is_method (#477), incremental builds kept a stale lsp_all.o compiled against the old 304-byte layout, while the rest of the tree recompiled against the new 312-byte layout — an ODR mismatch, so the by-value struct copy under-reads the shorter stale struct.

Clean builds (CI) always recompile both sides together, so the layouts match and CI never sees it. It only bites incremental developer builds after the struct changed.

Fix

Add an LSP_UNITY_DEPS prerequisite list (lsp/*.c, lsp/*.h, lsp/generated/*.c, internal/cbm/*.h) to both lsp_all.o and prod_lsp_all.o, so the unity object rebuilds when any included header or unity source changes. Wildcard-based, so new LSP resolvers (e.g. an added perl_lsp.c) are covered automatically. Explicit prerequisites rather than -MMD auto-deps, to match the Makefile's existing style.

Verification

• touch internal/cbm/cbm.h → lsp_all.o now rebuilds (it didn't before); no-op rebuild is a clean no-op.
• Clean build + full ASan test suite green; rustlsp_dbg_macro_inner_call no longer aborts.