1.0.5-rc.4 — release candidate (npm only)

1.0.5-rc.4 — npm-only release candidate

Coordinates (the tree at this SHA reads 1.0.4 / 8.0.4 — a pre-release version is
never committed, so this annotation is the only record):

npm 1.0.5-rc.4 14 packages, dist-tag next
PyPI not published for this candidate
NuGet not published for this candidate
Maven Central not published for this candidate

npm ONLY, by decision. All five ports changed product code on this SHA, so a
faithful rehearsal would have moved all four registries. The adopter estate that
gate G3d runs is a TypeScript application consuming @metaobjectsdev/* from npm,
and Phase 3 drives the other four ports through their own CLIs from this repo's
build rather than from a published package — so npm is what this candidate has to
prove, and a version number burned on three registries nobody installs from is a
cost with no evidence attached. Per ADR-0035 a lagging registry is INFORMATION,
not drift. Java, Python and NuGet publish at the real 1.0.5.

metamodelVersion stays 1.0.

BREAKING — metadata. A M:N junction that cannot be PAIRED is now a load error in
every port, so previously-loading metadata stops loading.

@through has always been documented as a junction declaring two
identity.reference children, ONE PER FK SIDE, and features/relationships.md
already said a reference naming anything else fails with
ERR_INVALID_RELATIONSHIP. The loader only ever counted the references; it never
checked what they point at. So an unpairable junction loaded clean and then
behaved differently in every port: TypeScript and C# warned and emitted no
traversal route — the endpoint simply 404s, with nothing in the build output a CI
gate would fail on — while Java, Kotlin and Python threw and failed the build.
One input, two contracts, and the quiet arm was the dangerous one.

This ships as a PATCH under the three-part correction bar in
docs/compatibility-policy.md: the form contradicted the documented contract, it
produced no correct outcome for anyone in any port, and the load error names the
exact repair. It has no registry-manifest footprint, which is precisely the class
the version gate cannot see — so the CHANGELOG answers it instead of the gate.

It also exposed a shipped bug it now fails loudly instead of silently.
TypeScript and C# resolved @through through a bare-name lookup that a
package-qualified name could never match, then fell back to the first entity with
that short name — so with two same-short-named junctions in different packages
the derivation paired against the WRONG junction and gave up, emitting no route
for a valid model. Java was already FQN-exact and unaffected. All four now
resolve through the one ADR-0041/0042 matcher the loader itself uses, which also
closes the deferred bare-collision gap (#174).

Also carries the empty-PATCH ruling: a body that strips to zero caller
assignments answers 200 with the current row in every port and both lanes, never
400 and never an empty-SET error. FR-037 PATCH-5 always said so; nothing in the
corpus asserted it, and the ports had drifted to five answers for one input.

What this candidate is for. rc.3 shipped with integration-tests red on its own
tag (fixed on main afterwards and proven green), so this is the clean green tag.
It also carries the F10 fix, unreleased until now, so the estate's
subtype-immutable-discriminator scenario stops being red during Phase 3.

Verified before publish: full scripts/ci-local.sh green, hosted local-ci green on
all nine jobs, and every port's own suite — TS metadata 2732 / codegen-ts 1702 /
runtime-ts 459 / docs-site 46, Java 1624 plus a green full reactor, C# 1978
across four dlls, Python 2227 including 135 integration, Java and Kotlin
integration lanes 126 and 147. The adopter estate loads with zero errors under
the new rule, with a control proving the rule is live on that same path.