fix: merge native records that repeat a model key

[dgnsrekt]

Fixes #50.

Problem

LM Studio can report one model once per host it is served from, each record listing only that host's loaded_instances. enhanceConfig maps records straight into an object, so Object.fromEntries keeps whichever is read last and the other host's instances are discarded before effectiveContextLength ever sees them.

The minimum is then taken over one record's instances instead of all of them, so limit.context can exceed what a routed instance actually has — the exact overstatement the conservative-minimum policy exists to prevent:

// same key, instances on two hosts
record[0].loaded_instances = [{ id: "host-A/model", config: { context_length: 8192   } }]
record[1].loaded_instances = [{ id: "host-B/model", config: { context_length: 262144 } }]

before:  entries=1  context=262144     <-- host A is advertised at 32x its allocation
after:   entries=1  context=8192

Not synthetic — my server reports 32 llm records under 29 distinct keys, 3 of them duplicated across two hosts. #50 has the full payload shapes.

Change

Merge records sharing a key before mapping:

• union loaded_instances, de-duplicated by id, so the minimum sees every reported instance;
• keep the smallest max_context_length, so a merged record never overstates any record it replaces;
• take remaining scalar metadata from the first record for the key — observed duplicates repeat it identically (same format, quantization, capabilities, max_context_length), differing only in routing.

discovered now counts distinct keys rather than raw records, so it agrees with the generated model map instead of overstating it, and mergedDuplicates reports how many records were collapsed.

I deliberately kept model identity unchanged. Giving routed instances distinct IDs would let a user target a specific host, but that is a contract change and belongs with #42 — this PR only stops the silent data loss.

Verification

6 tests added (27 → 33), covering distinct keys left untouched, instance union, id de-duplication, smallest-maximum, and the two integration cases from #50. Both integration tests fail on main:

× reports the conservative minimum across hosts instead of the last record's allocation
  AssertionError: expected { discovered: 2, …(5) } to match object { discovered: 1, mergedDuplicates: 1 }

× treats a key as loaded when only one of its records reports an instance
  AssertionError: expected 262144 to be 8192

npm run validate clean (lint, typecheck, 33 tests, build).

End-to-end against LM Studio 0.4.x via opencode models lmstudio:

	before	after
discovered	32	29
models listed	29	29
mergedDuplicates	—	3

discovered and the model map now agree. On this server every instance of a duplicated key happens to be allocated the same 262,144 context, so no reported limit changes here — the merge is what keeps that true once allocations differ.

Notes

Independent of #48 and #49, and based directly on main. It does touch enhanceConfig alongside #49, so whichever lands second may need a trivial rebase — happy to do that. Verifying against a live server needed #48 applied locally, since without it this server returns no models at all.

🤖 Generated with Claude Code

https://claude.ai/code/session_01S7Wjrr4wy4Eiig1PqtHfpD