Carry the exclusion widening into the second, dormant tree-sync pin

[gunbai-bot]

main is red, and this half of it is mine

test.claim.live_deploy.emit witness_scripts_stay_within_ci_runner_grants pins the tree-sync ExecStart to the exact two-prefix spelling:

ExecStart=/usr/bin/rsync -rlpt --delete --exclude /target --exclude /.git "${GUNBC_TREE_SRC}/" /opt/gunbc/gunbc/

#8522 widened deployed_tree_excluded_prefixes from two entries to six, so that string_contains no longer matches.

Why #8522 was green anyway — the part worth recording

Two witnesses assert those same emitted bytes:

• live_deploy_unit_emission_oracle_witness — enrolled, so the floor caught it, and Widen the deployed-tree exclusions to the host-state prefixes rsync was shipping #8522 updated it.
• this one — not enrolled at the time, so it could not be caught.

#8503 restored 14 modules and 226 witness identities, this claim among them, and it landed straight onto the already-merged change.

#8503 is not at fault. The restoration did exactly what restoring evidence is for: it made a previously invisible breakage observable. The defect merged hours earlier and simply had no executing consumer.

My error was a denominator error. I fixed the pin the floor showed me and inferred from a green run that no other pin existed. The correct question was which other claims assert these bytes — answerable with a grep at the time. A dormant witness is not a passing witness, and a green floor says nothing about the claims it never ran.

The fix

Same delta as the oracle row: the pattern gains the four host-state prefixes. The surrounding claim is otherwise untouched and still does its real job — apply and retract scripts must stay inside the ci-runner grants (no chown, no rmdir, no rsync outside the unit) — and that half never depended on the exclusion list.

Validated by execution

claim_batch on dag/test/claim/live_deploy/emit_test.dag, all 47 claims, on srv1 (aarch64): 47/47 PASS, 0 FAIL, including the previously-red witness_scripts_stay_within_ci_runner_grants.

The other red on main is NOT this, and not mine

v2.test.lens_inert_carrier.inert_carrier_test inert_carrier_no_unrostered_or_stale also fails on main. It is independent:

• it fails on main without any of my branch content, and
• a rebased branch of mine that ADDS a prose data row (Restore the serve socket seam as a frozen quarry route; keep converge refusing #8562) reported the same two failures rather than three — so my added carrier introduces no inert-carrier violation.

That one is still open and needs its own owner.