Repair the Release workflow, and lint workflows in CI

[louisbels]

What broke

#136 left release.yml unparseable. The secrets context is not among those available to a step-level if, so GitHub rejected the entire file:

release.yml:45:17: context "secrets" is not allowed here. available contexts are
"env", "github", "inputs", "job", "matrix", "needs", "runner", "steps",
"strategy", "vars"

My fault: the first draft used vars.RELEASE_APP_ENABLED (valid) and I "simplified" it to read the secret directly, without checking the context availability table.

Why it went unnoticed

This failure mode is unusually quiet:

• the run reports failure with zero jobs — nothing to open, no logs, --log-failed returns "log not found"
• the workflow list shows .github/workflows/release.yml instead of Release

Nothing else changes. Releases would simply have stopped working at the next changeset, and the reason would not have been obvious.

The fix

secrets is available in jobs.<id>.env, and env is available to a step if. So the check moves up one level:

    env:
      HAS_RELEASE_APP: ${{ secrets.APP_ID != '' }}
    steps:
      - name: Mint a GitHub App token
        if: env.HAS_RELEASE_APP == 'true'

Same behaviour as intended in #136, including the GITHUB_TOKEN fallback.

The gate

Added actionlint as a workflows job, and put it in docker's needs alongside the others.

Verified it catches this exact bug: run against the broken file it reports the error above; against the fixed one it exits clean. A workflow that fails to parse is the one class of CI failure the CI cannot report on its own, so it is worth a check rather than more care.

---

Note: the App is already installed and APP_ID / APP_PRIVATE_KEY are set, so once this merges the release path uses the App. The next "Version Packages" PR should carry the full check suite and be authored by the App instead of github-actions[bot] — that is the confirmation to look for.