#20085: Fix QMD memory_search empty results when docid key changes

Fixes #20082 Some QMD versions emit result objects with keys like `doc_id` / `docId` (instead of `docid`). The gateway parser treated these hits as missing doc IDs, so `resolveDocLocation()` dropped every result and `memory_search` returned an empty list. This normalizes common doc-id key variants to `docid` during JSON parsing and adds a small test for the alternate keys. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes a bug where `memory_search` returned empty results when QMD versions emit doc-id keys under variant names (`doc_id`, `docId`, `document_id`, `documentId`, `hash`, `id`) instead of the expected `docid`. The parser now normalizes these key variants during JSON parsing, along with `path`→`file` and `text`→`snippet` aliases. - Adds key normalization in `parseQmdQueryResultArray` to map common doc-id key variants to the canonical `docid` field - Explicitly constructs `QmdQueryResult` objects with only known fields (previously used a raw type cast on parsed JSON) - Adds test coverage for `doc_id` and `docId` normalization - The downstream consumers in `qmd-manager.ts` (`resolveDocLocation`, multi-collection dedup) already handle `undefined` docid safely, so this change is backwards-compatible <h3>Confidence Score: 4/5</h3> - This PR is safe to merge — it fixes a real parsing bug with a straightforward normalization approach and has no impact on the happy path. - The change is well-scoped, fixes a clear bug (empty results from variant key names), and downstream code already handles missing docid gracefully. One minor style concern about runtime type safety on the docid fallback chain, but it's unlikely to cause issues in practice since QMD document identifiers are string hashes. - No files require special attention. _{Last reviewed commit: 991bf1e} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->