Foundation: freeze and test the v3 reward-lane policy boundary

[wallscaler]

Parent design

Implements the smallest safe foundation from #426. This issue creates no reward lane, recipient, new allocation authority, policy signer, deployment, or chain write.

Why this comes first

The current repositories already have three related but non-identical pieces:

• Cathedral's current publisher describes a signed v4 scoring/vector boundary, with composition controlled by publisher configuration: weights.py.
• Distill already defines signed cathedral_burn_config_v1 and cathedral_lane_allocation_v1 documents, including network/netuid, signer, freshness, version, and conservation checks: signed_config.py.
• The validator's integrated preview currently accepts caller-supplied minimum config versions while verifying those signed documents: integration.py.

Before adding security, contribution, or maintainer rewards, we need one closed, durable policy-admission boundary. It must reuse the existing signed-config authority family, not create a second allocator.

Scope

1. Freeze a current-source compatibility matrix for Cathedral publisher, Distill signed config, and validator consumer. Resolve any terminology or contract drift from Design: post-launch security, contribution, and maintainer reward lanes #426 before implementation proceeds.
2. Specify a canonical, versioned reward_lane_policy_v3 extension of the existing signed burn/allocation authority. It must use closed lane IDs and integer units.
3. Add a durable validator-side policy-floor store. It must atomically persist network, netuid, policy version, policy hash, and release/publisher identity before an authoritative path can use the policy.
4. Add a shadow-only admission path and golden fixtures. It can parse and audit an admissible v3 policy, but it must not publish a vector, change the existing burn, change allocations, reward a recipient, or write on-chain.

Out of scope

• Activating any security, contribution, or maintainer lane.
• Issuing tickets, paying claimants, creating a security disclosure process, or admitting new miners.
• Replacing cathedral_lane_allocation_v1 or cathedral_burn_config_v1.
• Changing owner-controlled burn, allocation, signer, key rotation, or release policy.
• Mainnet/testnet weight writes, deployments, wallets, hardware, or spend.
• A second publisher or a new implicit environment-variable authority.

Acceptance criteria

• A reviewer can see the exact current contract mapping and which historical claims in Design: post-launch security, contribution, and maintainer reward lanes #426 were reconciled to current source.
• Canonical v3 bytes are deterministic. Unknown lanes, duplicate lanes, non-integer units, implicit re-normalization, invalid network/netuid, expired policy, unauthorized signer, and a burn destination receiving a positive reward all fail closed.
• Conservation holds exactly: sum(enabled lane units) + burn units == total units.
• The policy floor is durable across process restart and crash injection. A cache write followed by a floor-write failure cannot leave an older policy usable.
• A lower version, different hash at the same version, staging policy, or wrong network/netuid is rejected after restart.
• A shadow run produces a deterministic audit record but zero publisher calls, zero chain calls, and no mutation of existing v4/v2 behavior.
• Cross-repository golden tests prove identical admitted bytes produce the same verdict and audit identity.
• Existing production-facing vector tests continue unchanged. This issue does not claim deployed, live-hardware, or on-chain proof.

Safety boundary

This is an admission and replay-fence foundation only. An invalid candidate policy cannot reallocate a healthy existing lane. Until a later owner-approved activation issue passes its own gates, the current reward configuration remains the only authority.

@ai-hpc Please review the source-boundary mapping and the proposed durable-floor semantics before implementation. In particular, confirm whether there is existing validator-owned persistent state we should extend rather than add.