Migrate GitHub and Linear action resolution

[ndisidore]

Stacked on #238. Migrates the GitHub and Linear gatekeepers to applyActionsThrough, using the shared @gadgets/backend-utils/gatekeeper-action helpers (validateApplyThroughArgs, displayReason, SerialTaskQueue, and for Linear InvalidationLog). Both keep their existing disposal idioms and legacy per-action semantics (throw on unknown/settled — no silent no-ops).

GitHub

resolveActionVetoes applies direct vetoes plus GitHub's known dependency cascades (resource dependents of a vetoed creation; transitive reply chains, with direct-veto attribution precedence) to the stored records; the batch method retires the changed records and then applies pending actions ascending, stopping at the first failure with the specific apply error as stopped.reason. Attribution persists on retired records (GitHub's existing retire idiom), so repeated requests re-report invalidatedByVeto.

Fixes over the straightforward port:

• The batch sweep applies only "pending" records — never "staged" ones whose submitAction() hasn't completed (the contract forbids it; the old sweep would have applied them).
• Record mutation now invalidates the in-memory pending-overlay cache structurally: #putActionRecord/#retireActionRecord are the two storage chokepoints and clear #pendingActionsCache themselves, so no veto path can leave stale simulation overlays (previously each call site had to remember; the batch veto path didn't).

Tests move to @cloudflare/vitest-pool-workers so they run inside workerd: unit coverage of the cascade resolution plus DO-level batch tests against a real GitHubGatekeeperImpl facet (real staging flow and facet storage) covering cascade + re-report on retry, the legacy path refusing a cascade-invalidated action, unknown-veto tolerance, RPC-boundary validation, and legacy-reject attribution durability.

Linear

• applyActionsThrough per the contract: vetoes first (recursive provisional-issue cascade and label cascade keep deleting, now recording attribution in an invalidation: keyspace via InvalidationLog), then pending actions ascending with a status guard (the legacy applyAction had none and would re-apply settled records if asked).
• enqueue now writes records as "staged" and flips to "pending" only after submitAction() resolves (read overlays include both), and rolls the record back if submit fails — previously a failed submit left an orphaned pending record.
• All resolution methods serialize through one SerialTaskQueue.

Tested with pnpm build, pnpm lint:check, and the gatekeeper-github suite (17 tests, including the new DO-level batch tests).

[ask-bonk]

github run

[ask-bonk]

@ndisidore Bonk workflow failed. Check the logs for details.

View workflow run · To retry, trigger Bonk again.

[ndisidore]

Review of #241 turned up a correctness bug in the foundation branch that this PR copies: applyStoredActionsThrough silently skipping an in-range record whose submitAction() has not completed yet (record.state !== "pending" → continue / filter). The driver infers appliedThrough = stopped ? at-1 : actionId, so a silent skip lets it mark the staged action approved without it ever being applied — reachable whenever the batch RPC beats the submitAction() response (the hot path for auto-approved actions).

The foundation branch (#238) has been amended: a "staged" in-range record now returns {...invalidations, stopped: {at: record.id, reason: new Error("This action is still being submitted for approval. Retry in a moment.")}} instead of skipping, with tests pinning it in both gatekeepers.

When rebasing this PR onto the amended foundation, apply the same staged→stopped fix (and matching tests) to the gatekeepers here.