S-12: correct the shared fixture's alias prose, now that both runtimes

share one alias rule

selection-vectors.fixture.json's "//aliases" comment still called the
two alias forms a cross-runtime defect ("no candidate string that
resolves through both"). That was true before the Rust alias port; it
is not true now. Both runtimes resolve a schema alias the same one way
(strip a trailing .vN, compare the remainder against the descriptor's
declared SchemaName): nameAlias resolves through both, and hashAlias -
kept in the fixture on purpose - is refused as unmatched by both, since
neither runtime's production call sites produce or accept it.

Prose-only change to this shared fixture file, as ruled: no vector
values, schema ids, or row data touched.

Also recorded for Self's map: cultnet-rs's alias port (R-E) does not
carry SchemaVersion or CompatibleSchemaIds - no Rust call site needs
either, so schema_alias::matches folds them away and agrees with the C#
rule only on the subset it actually uses (candidate/id/name comparison,
not version or compatibility-list matching).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

contracts/cultnet/interop/selection-vectors.fixture.json

@@ -1,6 +1,6 @@
 {
   "//": "CultNet typed selection, Cut 1 fix batch (docs/cultnet-selection-cut.md, Self's rulings for the Cut 1 fix batch, R-E and the shared-fixture ruling, 2026-09-22). The one row set both the C# reference and cultnet-rs build their parity vectors from. schemaId is each schema's real SHA-256 content-hash id, exactly as GameCult.Caching.CultDocumentRegistry computes it for the fixture's C# document types (leaf_a=ParityLeafA, leaf_b=ParityLeafB, citer=ParityCiter, tests/GameCult.Networking.Tests/SelectionParityVectorTests.cs) - CultCache.cs's Sha256(semanticFingerprint), which carries no '.vN' suffix of its own; the version is folded into the hash, never appended as text. Both writers read this file instead of building their own fixture rows.",
-  "//aliases": "Two DIFFERENT alias forms, because the two runtimes' schema-alias matchers key off different attributes of a descriptor and there is no candidate string that resolves through both (this cut's confirmed report finding): nameAlias is <SchemaName>.v9, which CultNetSchemaAliasMatching.Matches(candidate, CultDocumentDescriptor) resolves by stripping the trailing .vN and comparing to descriptor.SchemaName (C#'s only real alias call sites all use this descriptor overload - src/GameCult.Networking/CultNetDatabase.cs:74-87 - never the schemaId-vs-schemaId overload). hashAlias is <schemaId>.v1, which cultnet_rs::selection::schema_alias::matches resolves by stripping the trailing .vN from EITHER side and comparing the remaining hash text - a mechanism C#'s production code path never invokes for `schemas`/`cites.target.schemaId` at all.",
+  "//aliases": "Two DIFFERENT alias forms, now deliberate rather than a cross-runtime defect (S-12, 2026-09-22: the Rust alias port made this so - see docs/cultnet-selection-cut.md, 'Self's ruling, 2026-09-22: the C# reference's alias rule is the rule'). Both runtimes resolve a schema alias the same one way: strip a trailing .vN and compare the remainder against the descriptor's declared SchemaName (CultNetSchemaAliasMatching.Matches(candidate, CultDocumentDescriptor), src/GameCult.Networking/CultNetDatabase.cs:74-87; cultnet_rs::selection::schema_alias::matches ports it name-for-name and deletes the hash-stripping overload it used to carry). nameAlias is <SchemaName>.v9 and resolves through both runtimes under that one rule. hashAlias is <schemaId>.v1 and is refused as unmatched by both - it is not a wire form either runtime's production call sites ever produce or accept, and it is kept in the fixture specifically to pin that neither runtime resolves it.",
   "schemas": {
     "leaf_a": {
       "schemaId": "sha256:ff35f3d9d6de3f1066b9369e73fe6c7648e88368d18efc2275c994730cd84cff",