fix: stop token-optimizer self-targeting the AIC monitoring family

[mrfelton]

Problem

The Phase 1 self-targeting guard in workflows/agentic-token-optimizer.md can never fire, so the optimizer selects itself (or its sibling audit) as the workflow to optimize. Full write-up in #119.

gh aw logs reports workflow_name as the display name (the H1):

• optimizer → Agentic Workflow AIC Usage Optimizer
• audit → Daily Agentic Workflow AIC Usage Audit

Neither contains the substring "Token", so Exclude workflows with "Token" in the name matches nothing. With the monitoring family always in the candidate pool, and sort_by(total_ai_credits) putting the always-on scheduled family on top (especially since gh aw logs only recovers ~24h and event-driven workflows mostly skip), the optimizer ends up "optimizing the optimizer".

Fix

1. Deterministic pre-filter in the Download step — drop runs whose workflow_path matches agentic-token-(optimizer|audit) or whose display name matches AIC Usage (Optimizer|Audit), so neither all-runs.json nor top-workflows.json can list the family (the agent reads both).
2. Correct the Phase 1 prompt guard to key off the real ids / display names instead of the "Token" substring.

Both workflows/ (template) and .github/workflows/ (active) copies are updated and kept identical.

Notes

• Source .md only. The generated .lock.yml files are intentionally not included: a fork compile produces repo-scoped cron jitter and resolves action-pin SHAs differently, so fork-built locks wouldn't match this repo's gh aw compile / install-workflows.yml output. Please regenerate locks in-repo.
• Validated with gh aw compile --validate --no-emit (v0.72.1): 0 errors, 0 warnings.
• Running in production in a large monorepo; after this fix the optimizer targets genuinely-expensive workflows.

Fixes #119

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com