[autonomy-atomicity] Global maintenance cron derived from min expires creates cross-workflow merge hotspot

## Autonomy / Atomicity Findings

### 1. Global maintenance schedule is coupled to per-workflow `expires` values
**Category:** Shared configuration hotspot
**File(s):**
- `.github/workflows/agentics-maintenance.yml` (lines 29-31, 36-37)
- `.github/workflows/gh-aw-stale-issues-investigator.md` (line 85)
- `.github/workflows/gh-aw-code-complexity-detector.md` (line 113)

**Problem:**
`agentics-maintenance.yml` documents that its cron is generated from the **shortest** `expires` value used anywhere:
- `"Schedule frequency is automatically determined by the shortest expiration time."` (`agentics-maintenance.yml:31`)
- current cron comment: `"Every 6 hours (based on minimum expires: 2 days)"` (`agentics-maintenance.yml:37`)

At the same time, workflow sources set different `expires` values (for example `2d` vs `7d` in the files above).

This creates a cross-workflow coupling point: changing `expires` in one workflow can regenerate the same global schedule line in `agentics-maintenance.yml`. Unrelated detector/fixer work can therefore collide on one shared file and produce avoidable merge conflicts/churn.

**Suggested fix:**
Decouple maintenance scheduling from per-workflow `expires`:
1. Use a fixed maintenance cron (or a bounded set of static schedules), and evaluate item expiration at runtime.
2. Keep `expires` semantics local to each workflow/output policy without mutating a global schedule derived from min(`expires`).
3. If dynamic scheduling must remain, generate it from a dedicated single-source config file (not distributed per-workflow settings) to isolate concurrent edits.

## Suggested Actions
- [ ] Decide whether `agentics-maintenance` should be fixed-schedule vs min(`expires`)-derived.
- [ ] Refactor generation so per-workflow `expires` changes do not rewrite global cron metadata.
- [ ] Add/adjust compile-time validation to prevent accidental reintroduction of cross-workflow schedule coupling.

> [!NOTE]
>
> 🔒 Integrity filter blocked 2 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - [#506](https://github.com/elastic/ai-github-actions/issues/506) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#107](https://github.com/elastic/ai-github-actions/issues/107) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
>
> To allow these resources, lower `min-integrity` in your GitHub frontmatter:
>
> ```yaml
> tools:
> github:
> min-integrity: approved # merged | approved | unapproved | none
> ```
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Autonomy Atomicity Analyzer](https://github.com/elastic/ai-github-actions/actions/runs/25813584911)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.