policy: record approval for the 19-line gates test deletion (Refs #9634)

[dmitrii-f-t27]

Refs #9634, #9622, #9630

This PR records an approval; it does not fix anything and does not close #9634 (no Closes; the issue gate accepts Refs #N). The fix of #9634 closes it later.

Draft. Data-only. Not merge-ready: its own-language check is red until the label owner-approved-foreign is applied, and duplicate-bodies is red for other reasons (see "Current CI"). This is not a request to merge a red PR.

Problem

PRs #9622 and #9630 fail the cli-tri check because of one obsolete unit test in cli/tri/src/gates.rs, the_motivating_workflow_records_its_own_reason. It reads .github/workflows/brain-seal-refresh.yml with include_str!, and master no longer has that file (deleted by 9a092df, #9117), so cargo build -p tri --all-targets exits 101 on master.
The fix of #9634 is a pure deletion: 19 lines deleted, 0 added. specs/policy/own_language.t27 classifies a modified .rs file by its status letter (M), so the gate denies it. The real local hook did: exit 1, DENY cli/tri/src/gates.rs (/tmp/t27-ci-cli-own-language.log; the same on the three-path fix, /tmp/t27-ci-9634-clean-own-language.log).

Safe order

lefthook.yml reads tools/policy/foreign-exceptions.txt from origin/master, and .github/workflows/own-language.yml reads it from the PR's base, so an entry on the same branch as the deletion cannot work. Therefore:

1. This data-only PR adds one entry. It changes the exception list, which the gate protects, so it needs the label owner-approved-foreign. The author account dmitrii-f-t27 has pull rights only; the label and the merge need @gHashTag.
2. After the entry is on master, the three-path fix (19-line deletion plus the census re-pin) goes through the ordinary hooks as the fix PR of cli-tri: retire deleted-workflow test and refresh measured census pins #9634. Alternatively the owner applies the prepared 19-line patch.

Owner approval, quoted

Source: the project owner's direct message in a chat with the coordinator, 2026-10-15 (America/Sao_Paulo). English translation of the Russian original: "I allow the exception for deleting 19 lines of an obsolete test in gates.rs, without adding Rust."
The permission covers exactly 0 added and 19 deleted lines in cli/tri/src/gates.rs. It does not cover other Rust, compiler.rs, FROZEN_HASH, guards or weaker tests, and it is not a standing permission for future edits. Nothing in this PR says @gHashTag has approved it.

Change (head c4ca0a9)

One file, tools/policy/foreign-exceptions.txt: 8 lines added, 0 deleted (a blank line, six English ASCII comment lines, one path entry cli/tri/src/gates.rs, no directory prefix). The comment names the date 2026-10-15, issue #9634, the source and the exact boundary, says it is not a standing permission, and that other edits "are not authorized by this approval".
No Rust is modified. No .t27 spec applies: the gate's behavior does not change, only the owner's data list gains one record.
Be precise about what the entry does: the gate's checker matches path prefixes, so the entry technically allows the whole file cli/tri/src/gates.rs. The owner permitted only the 19-line deletion with 0 Rust added, so the narrow scope is held by the owner's approval and by review of the fix diff, not by the checker.
The label owner-approved-foreign waives only the path check. It never waives the foreign-line budget (check_budget: at most 40 added foreign lines per file, 80 per PR, added not more than deleted), and this entry does not lift it.

Hook results and the label attempt (Codex, 2026-10-15 16:48-16:51 UTC)

• Ordinary git commit: pre-commit own-language and foreign-budget passed. Ordinary push to the fork: pre-push own-language and foreign-budget passed. No --no-verify, no LEFTHOOK=0. Author and committer Dmitrii Fedorov.
• Label attempt: gh pr edit 9639 --add-label owner-approved-foreign exited 1 with the exact answer GraphQL: dmitrii-f-t27 does not have the correct permissions to execute AddLabelsToLabelable (addLabelsToLabelable). The label is NOT set.

Current CI (not green)

• own-language: FAILURE, https://github.com/gHashTag/t27/actions/runs/38772157615/job/116550480148 (log /tmp/t27-ci-9639-own-language-ci.log, line 10: tools/policy/foreign-exceptions.txt: the Only-t27 gate itself is owner-only ... needs the owner's label owner-approved-foreign). Expected until @gHashTag applies the label.
• duplicate-bodies: FAILURE, the master-wide groups (duplicate-bodies: share tree helpers across eight gen_w bench ports #9633/spec(port): share tree helpers across eight gen_w ports (Closes #9633) #9636, ci: remove copied helpers from STEP1/STEP2 t27 ports #9631), not caused by this one-file data change.
• The other checks were still pending at 16:50 UTC. The full CI is not green and no green is claimed. The label alone will not make the whole CI green.

Proof that the fix itself is clean (not the CI of this PR)

On a clean worktree of master cd8a656 with the three-path fix (gates.rs 0 added and 19 deleted, tools/census/quiet.txt 2/2, shell.txt 4/4 by tri census pin --bless): cargo build -p tri --all-targets exit 0; cargo test -p tri -- --nocapture --test-threads=1 exit 0, 886 passed, 0 failed, 0 ignored, of which 3 are runtime Lean skips (lake is absent; the skip-watch baseline of 3, no new skip), so this is not 886 unrestricted executed checks;
tri census pin --gate and tri census explain pass (unchanged); tri skill check, tri gates tests --gate, and two existing census/NOW scripts pass; tri rtl check chips/phi --json 5 of 5 on CPU/Yosys (not a physical board). The staged fix in the ordinary hook: own-language exit 1 (DENY gates.rs, because the base has no entry yet), foreign-budget exit 0. Those results belong to the fix, not to this PR's CI.

Dmitrii Fedorov (@dmitrii-f-t27)

[dmitrii-f-t27]

@gHashTag, this follows up on the boundary request in #9634 (comment). Owner approval for the deletion is already recorded there, so I am not asking for it again.

New evidence since that request:

• The native carrier t27b: repair crypto and rust_convert; distinguish PR ledger lag #9637 at d8229d9 passed native Linux, macOS and ratchet in https://github.com/gHashTag/t27/actions/runs/38795387240.
• The 2,040-record run has UNEXPECTED FAILURE 0 and no JIT/interpreter mismatch or crash; known reference failures/timeouts are separate from regressions. The ledger is not blessed.
• These are 2,040 checked records, not 2,040 passing ones. No record that passes on the reference fails or times out natively.
• The native fix is independent of this PR and does not block a decision here.
• All 41 of my open PRs are still red. CLI is the most common failure (39 of 41).

This PR (head c4ca0a9) changes one data file: 8 lines of foreign exceptions, 0 Rust lines added. The CLI deletion prepared in #9634 is gates.rs with 0 added and 19 deleted lines, plus the standard census pin in two data files.

Requested action, one of:

1. After reviewing this exact boundary, apply the protected-policy label the gate requires to policy: record approval for the 19-line gates test deletion (Refs #9634) #9639; or
2. Apply the prepared deletion through your own authorized process.

My account has pull-only access. Adding the label was already refused, and I will not work around it. I am not asking anyone to merge a red commit or to bypass required contexts. I make no all-green claim.

Dmitrii Fedorov (@dmitrii-f-t27)