ci: build the flake in a non-gating job (task 0041)

A distinct `flake` job runs `nix flake check` on push and pull request,
catching flake rot — most concretely a build-relevant file left out of
package.nix's source allowlist — at the commit that causes it rather than
weeks later at the maintainer's next system rebuild.

The job is non-gating by two mechanisms: no `needs` edge, so it neither
waits on the test job nor is waited on, and `continue-on-error` so a red
build does not fail the run. That flag sits on the steps rather than the
job because Gitea's `act` fork declares it on its Step struct only and
silently ignores the job-level key; recorded as a Gotcha.

.claude/tasks/0041-ci-flake-build-job.md

@@ -14,7 +14,58 @@ Its cost is honest and accepted: because the checks output aliases the package,
 
 ## Acceptance criteria
 
-- [ ] A distinct job builds the flake on push and on pull request.
-- [ ] Its failure does not block or fail the other jobs.
-- [ ] Removing a build-relevant file from the source allowlist makes this job fail.
-- [ ] The job's cost and its non-gating intent are stated in the workflow so neither reads as an oversight.
+- [x] A distinct job builds the flake on push and on pull request.
+- [x] Its failure does not block or fail the other jobs.
+- [x] Removing a build-relevant file from the source allowlist makes this job fail.
+- [x] The job's cost and its non-gating intent are stated in the workflow so neither reads as an oversight.
+
+## Implementation Notes
+
+The job sits alongside `test` in the existing workflow rather than in a file of its own, so it inherits the `on:` triggers already there — push to `main` and every pull request — with no second copy to keep in step.
+
+Non-gating is achieved two ways, and both are needed.
+The absence of a `needs:` edge means the two jobs run concurrently and neither waits on the other, so a slow or failing flake build cannot hold the test job back.
+`continue-on-error: true` then keeps a red flake job from failing the workflow run as a whole, which is the part that would otherwise block a merge.
+That combination is what the criterion asks for; either alone leaves a gap.
+
+### `continue-on-error` goes on the steps, not the job
+
+The obvious spelling — `continue-on-error: true` as a job key — is inert on the platform this workflow primarily targets, and the first draft of this task had it there.
+
+Gitea Actions runs on a fork of `act`, and that fork's `pkg/model/workflow.go` declares `RawContinueOnError` on its **`Step`** struct only; the `Job` struct has no such field.
+A job-level flag is therefore parsed as an unknown key and silently ignored, so a failing `nix flake check` would have failed the whole workflow run — exactly the merge-blocking outcome the criterion forbids, and with nothing in the logs to say why.
+Gitea's own comparison page does not list the gap, which is presumably how it survives; go-gitea#25897 mentions it in passing while reporting the sibling gap in `jobs.<id>.if`.
+
+Moving the flag onto both steps fixes it and costs no portability: step-level `continue-on-error` is honoured by `act` and GitHub Actions alike, and a job whose every step carries it concludes green on either platform.
+The install step carries it too, not just the build — an action that fails to fetch or install Nix is precisely the infrastructure failure the non-gating stance exists to absorb.
+
+### `nix flake check`, not `nix build`
+
+The two build the same derivation, since the `checks` output aliases the package.
+The check output is what a consumer would verify with, though, so exercising that path additionally catches a `checks` output that has stopped evaluating.
+
+One limit worth recording: `nix flake check` builds the current system's outputs and merely *evaluates* the others, so the two systems the runner is not — `aarch64-linux` and `aarch64-darwin` — are type-checked rather than built.
+`--all-systems` would not change that; building them needs runners of those architectures.
+The job's value is the allowlist guard, which is architecture-independent, so this is a limit rather than a shortfall.
+
+### The allowlist criterion was verified, not assumed
+
+Deleting `./tsconfig.build.json` from `package.nix`'s `lib.fileset.unions` and re-running `nix flake check` locally fails the build in `buildPhase`:
+
+```
+> tsc -p tsconfig.build.json
+error TS5058: The specified path does not exist: 'tsconfig.build.json'.
+```
+
+`package.nix` was restored immediately afterwards; the probe is not in the diff.
+This is the failure mode the job exists to catch, and it confirms the loud-but-disconnected shape the 0037 Gotcha describes — the error names the missing file, never the allowlist that omitted it.
+
+### `cachix/install-nix-action` is a third-party action
+
+Nix is not in the runner image, so the job installs it.
+That is the one dependency in this file on an action outside `actions/`, resolved from github.com by Gitea Actions the same way `actions/checkout` is.
+It is also the most likely source of the infrastructure flakiness `continue-on-error` exists to absorb, which is part of why that flag is set rather than merely tolerated, and why the install step carries it as well as the build step.
+
+It is pinned to a mutable major tag (`@v31`), matching how `actions/checkout@v4` is pinned elsewhere in the file rather than introducing a second convention.
+A commit SHA would be the supply-chain-tight choice; the exposure here is a non-gating job holding no credentials and no `secrets` access, and pinning one action by SHA while the rest of the file uses tags would be inconsistent without being materially safer.
+Worth revisiting as a file-wide decision rather than a local one.