ci: advance the released suite pin to the rc.9 release commit

[ivanopcode]

Landing-order step 9, cocoaskills side (TASK-260824-1n98b3).

RELEASED_SUITE_PIN moves from 0c81c1f8d5321d822be2a2817b05aea03e656e15 (protocol 1.0.0-rc.6) to 0ed5c691e9208eea52f21db2fc05e226ce3516fd — the v1.0.0-rc.9 release commit on curator-spec main. That revision publishes the schema-8 suite this manager already qualified against on all three runners (run 32756144649, six candidate jobs, csk-schema8-results.xml tests=183 failures=0 errors=0 skipped=0).

The pin cannot move alone

Three places authenticate the released identity before reading a byte of the suite. Leave any one behind and the run goes red at collection rather than silently re-baselining — which is the property worth keeping, so all three advance in the same commit:

binding	what it pins	advanced to
tests/test_protocol_conformance.py	manifest digest, protocol_version, the release record it reads, the qualification vector's version	sha256:803918bf…, 1.0.0-rc.9, release/1.0.0-rc.9.json + claim_v5
tests/test_build_metadata.py	manifest digest, before the marker-v2 writer golden	sha256:803918bf…
.research/TASK-260803-2ol7ok_*	protocol revision, audited-file sha256s, ordered node-id baseline	0ed5c691, new digest, 1053 nodes

Collection delta: 8 nodes, and only 8

rc.9 is a strict superset of rc.6 — 0 files removed, 6 changed, 243 added — so the only effect on --collect-only is eight more test_rc6_generated_schema_case_is_consumed parametrisations, from the eight invalid-v8-* cases rc.9 adds under agent-skill-v6 and csk-skill-v6:

	rc.6	rc.9
baseline nodes	1045	1053
p00-contract-and-registry	565	573
p01…p05	444 / 9 / 9 / 10 / 8	unchanged

The eight new rows inherit the footprint, atomic cluster and shard of the 102 existing rows of that same function — verified uniform before copying, not assumed. No other node changes shard, cluster or footprint. What makes the classification diff large is source_line: it is re-measured from the current file for every row, and the audited file gained lines above most of them. audit_revisions records the change with the previous and new digest.

Test names keep the rc6_ prefix

Deliberately. They are the ordered node-id contract that the shard manifest and the isolation classification are keyed on; renaming them would rewrite every row of both for no behavioural gain. The module comment says so, and says what the module actually authenticates.

One deliberate omission

The released manifest digest is not repeated in ci.yml. Now that rc.9 publishes the qualified candidate's bytes, the released digest and the candidate declaration's digest are the same string, and test_no_rc6_literal_survives_outside_the_declaration forbids that string from appearing in the workflow. The comment explains the situation rather than weakening the gate.

Local evidence (darwin, py3.14)

Run directly, real exit codes:

• mypy — Success: no issues found in 75 source files, exit 0
• pytest tests/test_protocol_shards.py tests/test_protocol_shard_audit.py tests/test_ci_workflow.py tests/test_candidate_suite.py — 74 passed, exit 0
• pytest tests/test_builds_go_v1.py tests/test_build_metadata.py against the rc.9 root — 228 passed, exit 0
• the shard verifier run exactly as merge_protocol runs it — real --protocol-checkout at 0ed5c691 (clean), clean source checkout, fresh --collect-only output — exit 0 for all six shard ids: {"ok": true, "baseline_nodes": 1053, "classified_nodes": 1053, "gap": 0, "overlap": 0, "protocol_checkout_head": "0ed5c691…"}, selections summing to 1053
• the full tests/test_protocol_conformance.py against the rc.9 root — result recorded in the PR thread; this is the suite the decisive Windows shards run post-merge, so it is run locally before merge rather than discovered after it