adapter-rust: consolidate triplicated CodeLLDB platform-dir/candidate-path logic

[debugmcpdev]

Problem

The CodeLLDB platform-directory mapping and candidate-path-walking logic exists in three independent copies that can (and already did) drift:

1. Async resolver — packages/adapter-rust/src/utils/codelldb-resolver.ts (resolveCodeLLDBExecutable() / getCodeLLDBVersion()): platform/arch -> platformDir mapping + 4-candidate walk + CODELLDB_PATH fallback.
2. Private sync copy — packages/adapter-rust/src/rust-debug-adapter.ts (resolveCodeLLDBExecutableSync(), ~line 749): same mapping re-implemented with existsSync, a 3-candidate walk, and this.platform instead of process.platform.
3. Vendor script — packages/adapter-rust/scripts/vendor-codelldb.js PLATFORMS table: same five platformDir keys (win32-x64, darwin-x64, darwin-arm64, linux-x64, linux-arm64).

Evidence it bites

The version fallback in codelldb-resolver.ts was hardcoded to 1.11.0 while the vendor script default had moved on to 1.11.8. Fixed by exporting DEFAULT_CODELLDB_VERSION and adding a drift-guard test that greps the vendor script default (see packages/adapter-rust/tests/codelldb-resolver.test.ts), but the structural duplication remains.

Subtlety for whoever picks this up

The sync copy's candidate list is NOT simply "missing a candidate" — it is depth-adjusted. rust-debug-adapter.ts compiles one directory shallower than src/utils/codelldb-resolver.ts, so its '..' candidate resolves to the same package-root vendor/ directory that the async resolver reaches via '..', '..'. Any consolidation (e.g. a shared buildCandidatePaths(baseDir, platform, arch) helper) must take the caller's base directory as a parameter rather than using its own __dirname, or the two call sites will resolve different locations.

The platformDir mapping itself (platform/arch -> vendor key) has no such subtlety and is trivially shareable; the vendor script is plain JS run pre-build during postinstall, so it cannot import from src/ TS — sharing with it likely means a JSON/.cjs constant or keeping the existing drift-guard-test approach.

Suggested scope

• Extract one candidate-builder + platform-mapping helper in codelldb-resolver.ts (or @debugmcp/shared), parameterized on base dir.
• Make resolveCodeLLDBExecutableSync() consume it (sync fs walk over shared candidates).
• Decide whether the vendor script shares the mapping or stays guarded by test.