perf(objectql): index short name to FQN so registry lookups stop scanning the whole registry (#11102)

* perf(objectql): index short name → FQN so registry lookups stop scanning the whole registry

`SchemaRegistry.resolveObjectKey` answered the short-name direction by walking
every `objectContributors` key and calling `parseFQN` on each. Reached from
seven call sites including `getObject`, so a kernel boot that registers N
objects and resolves O(N) names did O(N^2) string work — the mechanism behind a
hosted environment whose bootstrap outgrew its request waiter and became
permanently unservable with no error anywhere.

Maintain a short-name -> FQN index Map beside `objectContributors`, mutated
only through two private choke points (`openObjectEntry` / `closeObjectEntry`)
so the two containers cannot drift. Resolution is unchanged: the index array is
the scan's `matches` list with the same members in the same order, so an
ambiguous short name still resolves to the first key registered under it and
the ambiguity warning still names every match.

Refs #10945

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RfyXxZ2WPjcjhuXpiQQc3y

* test(objectql): tune the registry scaling pin to the measured populations, add changeset

Ablation on this container: healthy ratio 5.7-11.1, full-registry scan 62.5.
Threshold placed between them (30x) rather than close to either, and PASSES
raised so the small window clears timer noise.

Refs #10945

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RfyXxZ2WPjcjhuXpiQQc3y

---------

Co-authored-by: Claude <pm@objectstack.ai>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: 3 people

.changeset/registry-shortname-index.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/objectql": patch
+---
+
+Index short name → FQN in `SchemaRegistry` so name lookups stop scanning the
+whole registry (#10945).
+
+`SchemaRegistry.resolveObjectKey` answered the short-name direction by walking
+**every** key of `objectContributors` and calling `parseFQN` on each. It is
+reached from seven call sites — `getObject` among them — so a kernel boot that
+registers N objects and resolves O(N) names did O(N²) string work, with
+`parseFQN` the largest non-database entry in the CPU profile.
+
+The consequence was a silence rather than a failure: boot got slower purely by
+an environment accumulating metadata, and once bootstrap outgrew the request
+waiter every request answered `kernel_warming` and the environment could never
+be opened — no error anywhere.
+
+`resolveObjectKey` now reads a short-name → FQN index `Map` maintained beside
+`objectContributors`. Both containers are mutated only through two private
+choke points, so they cannot drift apart: a caller cannot add a contributor
+list and forget the index half.
+
+Resolution is deliberately unchanged. The index array holds the same members in
+the same order as the list the scan built, so an ambiguous short name still
+resolves to the **first** key registered under it, the ambiguity warning still
+names every match, and the legacy `<ns>__<name>` fallback still works. That
+equivalence is pinned against the old loop itself, over every registration
+order, rather than against a hand-written expectation.
+
+Measured on the same container, resolving one name per registered object:
+
+| registry | 32,000 lookups over 4,000 objects | scaling ratio at 8× input |
+|---|---|---|
+| full-registry scan | 4,888 ms | 62.5× (quadratic) |
+| short-name index | 2.3 ms | 5.7× |