fix(survey): re-mint gate token before recheck; document App-install precondition

[marcusrbrown]

Two forward-looking hardening items on the Survey Repo privacy gate, both deferred from the cross-org survey fix.

• Re-mint the gate token before the visibility recheck. The App token is minted once at job start, but the survey agent runs between mint and recheck (up to the 30-minute job timeout). Installation tokens live ~1h, so today's envelope is safe — but if survey durations ever grow past ~50 minutes, the recheck could race token expiry and fail with a misleading 401. A fresh token minted immediately before the recheck keeps it well clear of the token lifetime regardless of survey duration. The early resolve-and-verify step keeps using the original mint.
• Document the App-install precondition. Four workflows depend on APPLICATION_ID / APPLICATION_PRIVATE_KEY being the fro-bot GitHub App installed on the fro-bot owner (update-metadata.yaml, dispatch-renovate.yaml, reconcile-repos.yaml, survey-repo.yaml). A comment block in update-metadata.yaml — the first cross-org App-token consumer — records the dependency.

actionlint clean. No behavior change on today's path.

Closes #3349

[fro-bot]

The token re-mint here is the right move: you minted the gate token at job start, then let the survey agent run for up to the full job timeout before the recheck. An installation token is a candle, not a star — it burns down on a ~1h clock from the moment of minting, and the recheck was reading by the original flame. Lighting a fresh one immediately before the visibility recheck keeps it well clear of expiry regardless of how long the agent drifts.

The implementation is disciplined:

• recheck-token is an exact mirror of the gate-token step — same pinned SHA (bcd2ba49... v3.2.0), same app-id/private-key/owner inputs. No drift in scope or trust surface.
• The if: guard (!cancelled() && steps.survey-agent.conclusion != 'skipped') matches the recheck step's guard exactly, so the token is guaranteed present whenever the recheck runs. No race where recheck fires against an empty steps.recheck-token.outputs.token.
• recheck is correctly rewired to the fresh token; the early resolve-and-verify keeps using the original mint, as described.
• The update-metadata.yaml change is comment-only — the App-install precondition is now documented at the first cross-org consumer. Zero behavior change there.

No new permissions, no untrusted input reaching a run: block, no secret echoed to logs. NODE_ID is still regex-validated before it touches the GraphQL call.

Verdict: PASS

Blocking issues

None.

Non-blocking concerns

• The two create-github-app-token invocations now duplicate the same four-line config (app-id/private-key/owner + pinned SHA). That's fine at two call sites, but if a third recheck-style gate appears, a composite action would keep the SHA pin in one place and prevent silent version skew between mints. Not worth doing now — three lines beats a premature abstraction.

Missing tests

None. These are declarative workflow changes (a token mint mirroring an existing one, and a comment block); there's no unit-testable behavior, and the PR notes actionlint is clean with no behavior change on today's path. The real verification is a live dispatch confirming the recheck authenticates against the re-minted token — that's integration territory, not a unit test gap.

Risk assessment: LOW

The new step is a structural clone of an already-trusted token mint with an identical guard; the only wiring change points one GH_TOKEN at a fresher source of the same scope. The metadata change is inert documentation. Worst plausible failure mode — the re-mint step itself erroring — surfaces as a clean step failure before the recheck rather than a misleading downstream 401, which is strictly better than the status quo.

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/.github
Run ID	26995356485
Cache	hit
Session	ses_169f63c98ffeURMu2lVaG8ARWk