C-428: stop re-running sentinel-review.yml's AUREA+ATLAS review on every PR touch

epicon_id: EPICON_C-428_CI_sentinel-review-trigger-hygiene_v1
ledger_id: kaizencycle
scope: ci, docs
mode: normal
issued_at: 2026-09-08T15:00:00Z
expires_at: 2026-10-08T15:00:00Z
justification: |
  VALUES INVOKED: cost stewardship, transparency, minimal-change discipline
  REASONING: The operator reported sentinel-review.yml (AUREA + ATLAS PR review) is costing too much in API credits. Reading the live workflow (not a generic template) showed the actual driver isn't model choice — under the default SENTINEL_DIRECT_FALLBACK=false config it never calls OpenAI/Anthropic directly at all, it calls the OAA broker. The real driver is trigger volume: an unscoped 'labeled' trigger (fires on ANY label add/remove, not just review labels) re-runs the full two-model review even when nothing code-relevant changed. Directly observed on Mobius-Substrate PR #448 earlier today: 5 separate sentinel invocations within about 5 minutes from routine iteration. Codex's review of this PR (#449) caught two gaps in the first version of this fix, both verified against the live workflow and corrected here: (1) an initial version dropped 'edited' from the trigger types entirely, but 'edited' also fires on a base-branch retarget — which changes the diff to review while leaving head.sha unchanged, so a stale Sentinel result could be accepted by the SHA-scoped Merge Gate against a materially different base; fixed by keeping 'edited' in the trigger types and gating on `github.event.changes.base != null`, which GitHub only sets on a retarget, not a title/body edit. (2) the job-skip `if:` alone doesn't prevent an ignored labeled/edited event from cancelling an in-flight real review, because workflow-level `concurrency:` with `cancel-in-progress: true` applies before a job's `if:` is evaluated; fixed by moving `concurrency:` from workflow level to job level, so a job skipped via `if:` never enters the concurrency group and can no longer cancel a running review. This EPICON record exists because this workflow's own REQUIRE_EPICON/REQUIRE_DOCS hard rule requires a docs/epicon/* and docs/*.md record on any PR it reviews - this file satisfies both while documenting the actual change.
  ANCHORS:
    - .github/workflows/sentinel-review.yml (SENTINEL_DIRECT_FALLBACK default 'false' — OAA broker path, not direct vendor calls, under normal operation)
    - Mobius-Substrate PR #448 check-run history, 2026-09-07/08 (5 sentinel job runs within ~5 minutes from routine PR iteration)
    - GitHub Actions docs on pull_request event types (`edited` fires on title/body/base-branch changes, distinguishable via `event.changes`; `labeled` fires on any label change, not label-name-scoped)
    - Codex review, Mobius-Substrate PR #449, 2026-09-08T15:04:29Z (discussion_r3959323190 base-retarget gap; discussion_r3959323195 concurrency-cancellation gap)
    - GitHub Actions docs on `concurrency:` — job-level concurrency is evaluated only for jobs whose `if:` resolves true; a skipped job does not join the group
  BOUNDARIES: Trigger hygiene only — keeps 'edited' and adds a job-level `if:` that skips (not fails) the job for a 'labeled' event whose added label isn't review:aurea/review:atlas/consensus:requested, or for an 'edited' event that isn't a base-branch retarget. Moves `concurrency:` from workflow level to job level with the same group/cancel-in-progress semantics. Does not change the C-339 fail-closed/skip-vs-fail decision logic, the OAA broker URL or protocol, model selection, or REQUIRE_EPICON/REQUIRE_DOCS enforcement. No production mutation, no credential or secret access.
  COUNTERFACTUAL: If a genuinely-new-review-relevant 'labeled' or non-retarget 'edited' event turns out to need a fresh review (none identified), or if Merge Gate's SHA-scoped check is found to behave differently than analyzed, this change should be reverted and re-diagnosed.
counterfactuals:
  - If a future scenario needs sentinel review to react to something other than a base-branch retarget within an 'edited' event (none currently exists), this fix would need to be revisited.
  - If Merge Gate is found to require a check-run against every trigger event rather than being SHA-scoped, revert this change.
  - If GitHub Actions changes concurrency semantics so a skipped job's `if:` no longer excludes it from the concurrency group, the job-level concurrency move stops fixing the cancellation gap and needs re-diagnosis.