fix: require submitted stage identities in catalog order

[Freshair129]

Summary

This PR closes owner decision GKS-PIP-001 from the P1 report. Until now, a GenesisRAG17 batch was accepted with its nine stage identities in any order.

Change (packages/gks-contracts/src/pipeline.mjs, validateStageIdentities)

Where	Rule
gks_pipeline_submit (batch.stages)	Stages must be listed in catalog order, 9 through 17. Any other order is gks_invalid_request, and the message names the first position that is wrong, for example stages[1] must be stage 10: stages are listed in catalog order, 9 through 17.
gks_pipeline_graph_receipt and gks_pipeline_write_receipt (receipt.stages)	Unchanged: order does not matter (catalogOrder: false).

The existing checks run first and their messages are unchanged: exactly nine identities, no duplicates, and each stage under its own DPS-KI-* id.

Why receipts stay order-insensitive

• Persistence already matches a receipt to its stored decision after sorting the stages (sameStageIdentity).
• A decision stored before this rule keeps the order it was submitted in, and the Tier-4 worker echoes the decision's stages back. Requiring catalog order on receipts would leave such decisions unable to complete.
• Receipt hashes are computed over the stages in the order they arrive. Sorting them in normalization would make previously recorded receipt replays hash differently and be refused as conflicts.

Compatibility

The real producer is zuri-ai's buildGenesisRag17StageIdentities (apps/server/src/modules/knowledge/genesisrag17-contract.js). It already builds the identities by looping from stage 9 to 17, so it always emits them in catalog order. MSP forwards the batch unchanged. This repository's makeBatch fixture also builds them in catalog order.

Golden corpus

• Before the fixtures were rebuilt, check:corpus replayed all 24 cases unchanged.
• C0.4-TOOL-010 (the submit case) gains an outOfOrder step: a batch with stages 10 and 11 swapped. It expects gks_invalid_request and pins the exact message.
• After re-baselining, only that case's transcript changes.

Docs

• GKS-PORT-CONTRACT 0.10.2b: the "Stage identity and receipt ordering" section now states the rule and why receipts are exempt.
• ADR-GKS-GENESISRAG17 0.5.3b: new revision row.
• P1 report: the GKS-PIP-001 row is marked done.

Test plan

• tests/contract/c0-acceptance.test.mjs adds:
  • two rejection cases, stages 10/11 swapped and a fully reversed list;
  • a test that pins the exact message;
  • a test showing that a graph receipt with its stage identities reversed is still accepted.
• npm test: vitest 298 passed, 2 skipped (the MSP suites need MSP_REPO_ROOT); security 12/12.
• npm run check:c0 (PASS 24 / NOT_RUN 1), check:baseline and check:corpus pass.
• CI on this PR

🤖 Generated with Claude Code