fix(railway): watchdog never paginates — GitHub rewrites next links to the repository-ID path (#6378) - #6469

…o the repository-ID path

`#paginate` compared GitHub's `rel="next"` URL against a synthesized
`/repos/<owner>/<repo>/...` path and threw when they differed. GitHub always
rewrites paginated Link headers to the numeric repository-ID form
(`/repositories/1130564872/statuses/<sha>`), so the comparison never matched
and every multi-page read failed closed with `next link was not exact`.

Main's head carries more than 100 statuses, so `readNewestGate` always saw a
next link and always threw. The watchdog therefore returned DEFERRED_AMBIGUOUS
on every scheduled run while reporting success, and could never have
classified or dispatched a recovery after the cutover.

Every mock in the suite built its next link from the request pathname, so the
assertion echoed back the one form the real API never returns and the tests
could not fail.

Follow the origin's link only as a boolean "another page exists" and synthesize
the next request from our own allowlisted path. The origin no longer routes a
watchdog request at all, which also keeps the `#authorize` allowlist meaningful
— the old code fed it an absolute `/repositories/<id>/...` URL it would have
rejected as GITHUB_ENDPOINT_FORBIDDEN. Completeness stays enforced by the frozen
total_count, duplicate-id, and truncation invariants.

The former 'skipped next page' rejection case is unreachable now that the walk
is synthesized; it is replaced by a positive test proving an origin-advertised
page number is ignored and every page is still walked.

Refs #6378

Railway cannot issue a read-only token. `apiTokenCreate` takes only
`{name, workspaceId}` and inherits the creating user's permissions;
`projectTokenCreate` takes only `{projectId, environmentId, name}`. The VIEWER
value on ProjectRole/TeamRole applies to project members — user accounts — not
to tokens, so a genuinely read-only token needs a separate Railway account
joined as a VIEWER member.

The runbook promised "The Viewer token must not be able to deploy, redeploy,
edit configuration, or approve Railway work." That is a credential-level
guarantee no Railway token provides, and the preview, verifier, and proof jobs
are all built on it. Say instead where the property actually comes from: the
--workflow-authorized fence in scripts/trigger-railway-deploys.mjs and the
workflow contract tests.

Also records that projectTokenCreate rejects a CLI session with Not Authorized,
so both tokens must be minted from the dashboard.

Refs #6378

…erson

The provisioning table asked for "independent reviewers and prevent self-review"
on ingestion-acceptance-production-breakglass. The environment now requires a
reviewer, so resolve pauses for a human and GitHub records the approver, but
prevent_self_review is deliberately off.

Enabling it with one reviewer would deadlock the emergency path: the only person
able to dispatch recovery would be barred from approving it, precisely when
recovery is needed. Two-person control requires adding a second named reviewer
first, so record that the `approver` input remains an audit assertion rather
than a verified second party.

Refs #6378