Mint Ephemeral Tokens

I'd like to:

1. Stop relying on callers passing GH_AW_GITHUB_TOKEN via job outputs
Today consumers do:

GH_AW_GITHUB_TOKEN: ${{ needs.mint-gh-aw-github-token.outputs.token }}

Masked installation tokens often do not survive as job outputs into the next job / nested workflow_call secrets: map. The product fix is not “smarter callers”, it is minting (or otherwise supplying the token) inside the lock workflow, without crossing that boundary.

2. Mint inside every job that actually uses GH_AW_GITHUB_TOKEN
The generated lock workflows (e.g. gh-aw-issue-triage.lock.yml) use secrets.GH_AW_GITHUB_TOKEN in several jobs, not only the agent container job—for example activation, agent, safe_outputs, conclusion, etc. (anything that passes github-token: or env derived from that secret).

So the pending work is roughly:

For each such job: add permissions: id-token: write (minimum on that job), a first step elastic/oblt-actions/github/create-token@v1 (with the right token-policy / catalog story your org uses), and wire later steps to steps..outputs.token (or job env built from that step) instead of secrets.GH_AW_GITHUB_TOKEN when no caller secret was provided—or always prefer mint for Elastic if that is the policy.
Re-run make compile so *.lock.yml matches the edited *.md / fragments (lock files are generated; do not hand-edit as the long-term source of truth).
Importing a fragment only into runtime-setup.md is not enough by itself: that path mainly affects the agent job’s setup steps; it does not automatically fix activation / safe_outputs / conclusion unless the gh-aw pipeline applies the same bootstrap there or the compiler gains a first-class “ephemeral GitHub token step” hook for all token-consuming jobs.

3. Contract / docs
Decide whether GH_AW_GITHUB_TOKEN stays as an optional override (PAT or pre-minted token) or becomes deprecated for Elastic ingress once in-workflow minting is the default.
Update gh-agent-workflows/*/README.md (and any consumer docs) so they say callers should omit GH_AW_GITHUB_TOKEN when OIDC + create-token is used inside the lock workflow.
4. Same idea for other lock workflows that need ephemeral mutations
Any other gh-aw-*.md that documents GH_AW_GITHUB_TOKEN for “labels/comments must re-trigger workflows” needs the same in-workflow mint pattern (or an explicit decision that those flows only use GITHUB_TOKEN and accept no re-triggers).