TypeSchema: kind-key the TypeSchemaIndex slot

[ryukzak]

Preparatory refactor for the SnapshotProfileTypeSchema work in #158.

Why

Today the index is Record<url, Record<pkg, TypeSchema>> — one entry per [url, package] slot. The upcoming SnapshotProfileTypeSchema shares url + package with the raw ProfileTypeSchema it's built from (they differ only by identifier.kind), so both can't live in the same slot. The current snapshot work (#158) sidesteps this with a parallel `snapshotIndex` — workable but adds bookkeeping.

This PR makes the slot kind-keyed so any future schema variant sharing url+package can coexist with its base. No current functional benefit; lands as pure preparation.

What

• _schemaIndex shape: Record<url, Record<pkg, Partial<Record<kind, TypeSchema>>>>.
• append() keys writes by identifier.kind; duplicate check moves to the kind-keyed slot.
• resolve(id) and resolveType(id) look up by id.kind, with a fallback to whatever's at the slot when the requested kind isn't present. The fallback preserves pre-refactor behavior — some IRs (CDA, specifically) declare dependency identifiers with a different kind than the actual stored schema, and the old slot-only lookup tolerated that.
• resolveByUrl picks the first entry from the slot (single kind today; the caller has no kind to disambiguate).

Verification

• bun run typecheck clean.
• bunx biome check clean (only pre-existing warnings).
• bun test 257/257 pass.
• R4 + US Core examples regenerate byte-identical.

[ryukzak]

Closing — the separate `snapshotIndex` approach (in #158) is the better solution after reflection:

• Mirrors the existing `nestedIndex` pattern that's already established for the same reason (URL collisions between parent specializations and their nested types).
• Cleaner per-index types — no `Partial<Record<kind, TypeSchema>>` indirection layer at the storage level.
• No need for the same-slot fallback workaround. That fallback was masking a real semantic: `resolve(id)` lookups that don't care about `kind` (and the CDA case where dependency identifiers carry a different `kind` than the stored schema). Treating that as the natural behavior of a slot-only index — rather than as a fallback inside a kind-keyed index — is more honest.
• Reads stay simple — no fall-through logic in the hot path.

Snapshots will live in their own `snapshotIndex` parallel to `nestedIndex`. #158 already implements this.