ci: bump ops-routines-workflows shims to v0.6.1 + enable PR comments

[justin-layerv]

Why

When dependabot bumps a recently-released action / Go module / docker base image / npm or pip package, the age-check workflow correctly blocks merge until the pin clears the quarantine. Until v0.6.1 the eligible-after date was only in the run log; now it lands as a sticky comment on the PR itself — one row per too-new pin (id, age, eligible date, days remaining).

What

For each age-check shim (.github/workflows/dependency-age-check-*.yml):

1. Bump pinned reusable to v0.6.1 (4edea7408d64f424780e08f68a54000308817a08).
2. Set comment_on_failure: true.
3. Grant pull-requests: write at the calling job. This is what makes the comment actually post on Dependabot PRs (Dependabot's token defaults to read-only; without the grant the post-step soft-fails to a ::notice and the comment is suppressed — the check itself still runs and blocks merge correctly).

For non-age-check shims (issue-priority / validate-issue-templates / dispatch-deploy if present): pin bump only. v0.6.1's dist for those reusables is byte-identical to earlier versions; the bump is purely version-alignment.

What is unchanged

• The age-check logic itself (still blocks new pins under the configured min_age_days).
• The age-check-bypass label still works.
• The required-check job names are unchanged in v0.6.1, so branch protection will not trip.
• No behavior change for non-failing PRs.

Refs

• v0.6.1 release: https://github.com/layervai/ops-routines-workflows/releases/tag/v0.6.1

[claude]

Review — ci: bump ops-routines-workflows shims to v0.6.1 + enable PR comments

Tight, well-scoped CI change. The diff matches the description, the rationale is captured inline next to each new key, and the blast radius is limited to two age-check shims (the other two are pin-bump only). LGTM with a few non-blocking observations.

What's good

• SHA-pinned with version comment (@4edea7408… # v0.6.1) on all four shims — third-party-action best practice preserved.
• Least-privilege expansion. Workflow-level stays at contents: read; pull-requests: write is added only on the calling job that needs it. The other age-check job (and the issue-priority/validate shims) are unaffected.
• The inline comment explaining why the grant is needed is exactly the right level of detail — the Dependabot read-only-token quirk is the kind of thing future-you will forget in 6 months. Worth keeping.
• Conventional-commit ci: prefix matches CLAUDE.md guidance, so Release Please will categorize correctly.

Things worth a look (none blocking)

1. Stale sticky-comment edge case under cancel-in-progress: true. Both age-check shims use cancel-in-progress: true on the concurrency group. Scenario: run A posts a sticky comment for a too-new pin; the user pushes a fix; run A is cancelled mid-flight; run B passes and should delete the comment. If the reusable's "delete on clean pass" step runs only at the end and is idempotent on the next failure, you're fine. If it relies on state from a non-cancelled prior run, you could leave a stale comment behind until the next failure overwrites it. Worth a quick sanity check against the v0.6.1 reusable's logic — but this is upstream behavior, not something to fix here.

2. Fork-PR (non-Dependabot) behavior is correctly documented but worth re-stating for reviewers: for PRs from forks, GITHUB_TOKEN is read-only regardless of permissions: grants — only Dependabot PRs honor the explicit pull-requests: write. The inline comment captures the soft-fail-to-::notice behavior, which is the right outcome (the gate still blocks merge; only the convenience comment is suppressed).

3. PR-description claim about issue-priority / validate-issue-templates being byte-identical at v0.6.1. Reasonable to bump in lockstep for version alignment, and I trust the description, but it's a claim that's worth verifying once at the source repo before merging if you haven't already — a silent behavior change in those reusables would land here too.

4. Minor — comment duplication. The "Required for comment_on_failure: true to actually post…" comment is repeated verbatim in both age-check shims. Acceptable since they're independent files and the comment matches each one's local context, but if you ever centralize the shim boilerplate (or generate it from a template), this is a candidate.

Code quality / bugs / perf / security

• Code quality: clean. YAML indentation correct (job-level permissions aligned with uses/with).
• Bugs: none spotted.
• Performance: N/A — the new keys don't change the run's hot path; the comment post-step is a single API call gated on failure.
• Security: SHA-pin preserved, permissions narrowed to the specific job, no pull_request_target exposure. ✓
• Test coverage: N/A for shim YAML; behavior is owned by the upstream reusable.

Final verdict

Approve. Recommend merging once you're satisfied with point (3); the other items are observations, not changes.