canary-rollout: role-scope the stale-release check and bound the candidate-window ingress read (#1244 items 4, 5) #1247

Summary

Two scoping questions from the #1238 review (tracked in #1244). Neither is a known fail-open; both need verification and a decision.

Items

• Item 4 — _run_is_stale role scoping. The reviewer says another role's pinned release in a shared ingress run could mark this agent's failure as an old-release failure. _run_reusable_sha only keeps Uses: lines for the agent's own reusable, so a pin to a different reusable cannot match. The open case is two roles in one ingress run calling the same reusable at different pins: _run_reusable_sha is not role-scoped (no job-name prefix filter). Verify, and add tests either way: (a) different reusable, (b) same reusable at a different pin.
• Item 5 — candidate-window cap. The strict CANARY_INGRESS_JOBS_MAX (default 300) cap still marks a member UNRESOLVED when the candidate window (cut to now) holds more ingress runs than the cap. Only reachable on a very busy repo after a long soak, but all roles share the ingress, so it can freeze promotions fleet-wide. Candidate: bound the read by a per-role attributed sample instead of raw run count.

Open decisions

1. Keep the cap at 300, raise it, or replace it with a per-role sample bound? Each run costs one gh run view --json jobs, so this is a rate-limit headroom question.
2. Collapsed member that does not carry a registered role. Today it is UNRESOLVED and holds the gate until it carries the job or leaves the ring (the legacy path returns []). Per the principle that expected outcomes must not be failures, should a legitimate non-consumer instead be "no caller"? That depends on how a non-consumer is told apart from template drift; see item 10 in the sibling issue.

Acceptance criteria

• Item 4 fixed or closed as "does not reproduce", with tests for both cases.
• Item 5 resolved per the decisions above.
• Existing end-to-end tests pass unchanged; shellcheck --severity=warning -x clean.

Refs #1244, #1238.