Problem #1224

Problem

The 9-archive district move (#1218) turned the Scorecard check red:

2 new alerts including 2 medium severity security vulnerabilities

Both annotations are Pinned-Dependencies ("downloadThenRun not pinned by
hash") at

• 9-archive/rhodium-standard-repositories/templates/setup.sh.template:144
• 9-archive/rhodium-standard-repositories/templates/setup.sh.template:156

Both are curl -fsSL https://just.systems/install.sh | bash.

These are not new code. The file is a byte-identical rename — verified by
SHA256 against its pre-move path — and the same two lines exist at the same
line numbers in 7712ae1. Scorecard's "new alerts in code changed by this
pull request" heuristic sees 1,136 renamed files as new code, and says so:
"Alerts not introduced by this pull request might have been detected because
the code changes were too large."

Why it should not be "fixed" by editing the file

The file now lives in 9-archive/, a frozen district. Its map entry says
lifecycle = "frozen" and records that contents "MUST NOT be edited for
conformance — a change made here to satisfy a gate would falsify the historical
record." .githooks/validate-k9.sh exempts the district on the same reasoning.
Editing an archived template to appease a scanner is exactly the drift the
district exists to prevent.

What is needed

A policy for archived content versus repo-wide scanners:

1. Dismiss the two alerts with a recorded reason, or
2. Configure the scanner to exclude the 9-archive/ district, or
3. Route archived findings through the existing baseline mechanism
   (scripts/filter-sarif-by-baseline.sh).

Option 3 is probably right, and is the one consistent with the estate's
existing doctrine. Option 1 needs a token with security scope — the session
token returns 403 on code-scanning/alerts.

Acceptance

• One of the three, chosen deliberately.
• The choice recorded wherever scanner policy is documented.