[aw-maintenance:compiler-security] Compiler exit 1 on daily-runtime-threat-scan.md: zizmor strict mode fails despite 0 findings

**Executive summary**: Compiling `github/gh-aw-actions` failed (exit code 1) on the single workflow source `.github/workflows/daily-runtime-threat-scan.md`. actionlint passed with no reported errors, but zizmor's strict-mode gate reported failure while explicitly stating "0 security warnings/errors" were found — an internal contradiction suggesting a compiler/zizmor-invocation bug rather than an actual security finding. Recommended next action: investigate the zizmor strict-mode check logic (likely a non-zero exit code from the zizmor process being misinterpreted as "findings present" even when it reports zero), then rerun the local fixing loop below to confirm.

- **Target repository**: `github/gh-aw-actions`
- **Compiler exit code**: `1`
- **Workflow sources checked**: `1`
- **Generated lock files checked**: `1`
- **Result**: `findings`

### Findings

| Tool | Workflow/Image | Severity | Finding | Remediation |
|------|-----------------|----------|---------|-------------|
| zizmor (via gh-aw compile, strict mode) | `daily-runtime-threat-scan.lock.yml` | unknown | Strict-mode gate reports failure ("zizmor found 0 security warnings/errors ... workflows must have no zizmor findings in strict mode") despite explicitly stating 0 findings — likely a compiler bug misinterpreting zizmor's exit status rather than a real vulnerability | Investigate gh-aw's strict-mode zizmor result parsing; confirm whether zizmor itself exited non-zero for an unrelated reason (e.g. tool error) vs. the wrapper mis-flagging a clean scan as failing |
| actionlint | `daily-runtime-threat-scan.lock.yml` | n/a | No errors reported | none needed |

The generated lock file diff also shows substantial unrelated regeneration churn (399 insertions / 231 deletions), consistent with a normal recompile against a newer gh-aw compiler version rather than a source edit.

### Local fixing loop

1. Install or update the gh-aw extension, then configure the coding agent's MCP client to launch `gh aw mcp-server` over stdio from the target repository (`github/gh-aw-actions`).
2. Give the agent the prompt below and require it to use the `fix` and `compile` MCP tools rather than editing generated `.lock.yml` files.
3. Require the agent to repeat the same full compiler validation and security scan until it passes, or stop and explain any finding that needs human action.

Agent prompt

Fix the reported gh-aw compiler and security findings in this repository. Change only `.github/workflows/*.md` sources and directly related files; never edit generated `.lock.yml` files. Use the gh-aw MCP server's `fix` and `compile` tools, rerunning compilation with strict validation, model checks, actionlint, shellcheck, yamllint, zizmor, poutine, runner-guard, grant, grype, and syft until clean. Review generated lock-file diffs, preserve existing behavior, and stop with a concise explanation if a finding cannot be fixed safely. In particular, determine why zizmor's strict-mode check fails even though it reports 0 findings for `daily-runtime-threat-scan.lock.yml`, and confirm whether this is a compiler-side bug rather than an actual security issue.

Raw compiler output (report.txt)

Start by reproducing the failure with `gh aw compile` for `.github/workflows/daily-runtime-threat-scan.md`, using the generated `daily-runtime-threat-scan.lock.yml` and the reported zizmor output. Trace how strict mode handles zizmor's process result versus its reported finding count. Done means a clean zero-finding scan no longer causes a compiler exit of 1, while genuine zizmor findings still fail strict mode.

Written by the indexing model from the issue text.