chore(auth): stage certification count boundary ceiling

[bokelley]

Summary

• append organization_certification_stalled_count_read to the production deployment ceiling
• leave the audited database runtime setting unchanged at the five currently enabled boundaries
• keep the candidate disabled until this configuration deploy converges and completes a clean disabled soak

Scope

This PR changes exactly one fly.toml line. It does not activate the boundary, change route behavior, or modify the database runtime setting.

Verification

• default-off code PR feat(auth): add certification stalled count canary #7320 passed independent code, security, and test review plus full GitHub CI
• default-off deployment converged successfully
• a fresh 15-minute post-convergence disabled soak passed with exact configuration, healthy services, 56 worker jobs with zero failures, and zero candidate decisions, unavailable decisions, organization-route errors, API errors, or exceptions
• git diff --check passes
• Docker-based local testing was unavailable because this Cloud VM has no running Docker daemon
• the normal pre-commit suite passed 1,058 of 1,059 root tests; the remaining test hit the existing test-aware typecheck failure in an untouched reporting file, so clean GitHub CI is mandatory

Rollout

After merge and successful fleet convergence, verify runtime-five/ceiling-six separation and complete a clean disabled soak before any audited runtime activation.

Issue: #6827

---

Open workspace in Conductor

[aao-secretariat]

Ladon verdict: Approve

Approve — one-line operational config change to fly.toml.

What I checked:

• Single-line change appending organization_certification_stalled_count_read to the ORG_AUTHORIZATION_ENFORCEMENT_BOUNDARIES deployment ceiling. Boundary name matches the code constant exactly and is wired at certification.ts.
• Deployment/operational-only change — no touch to static/schemas/source/**, docs/**, dist/**, or protocol surface, so no changeset is required and schema↔docs coherence is not implicated.
• The separate audited DB runtime gate still governs actual enforcement (fail-closed), so this stages without activating.

No blocking, Medium, or Low findings. gated_paths is false and high_risk is false. review_decision is REVIEW_REQUIRED, but no gate (path-based or prose-based) applies to this operational change, so the PR falls through to row 9 → approve.