feat(config): Add postChecks toggle to disable GitHub Check-run posting

[CalebKAston]

Summary

Adds a postChecks boolean (action input post-checks, default true; overridable per-repo via warden.toml's [defaults] postChecks) that disables creation/update of GitHub Check runs — the core warden check and every per-skill warden: <skill> check, including their inline annotations — while leaving PR review comment posting untouched.

Why

Check-run creation is entirely write-only today: nothing in the codebase reads it back via the API, and it isn't load-bearing for the findings-output file or for comment dedup (which reads back PR review comments instead, a separate mechanism). Some teams want PR review comments as the single review surface without a second, non-threaded, non-dedup'd GitHub Checks UI surface running alongside it — this makes that toggleable without losing the option to fail a required status check via fail-check/fail-on when wanted.

Implementation

• Single choke point: checkOptionsForPullRequest(context, postChecks) returns undefined when postChecks is false. Two call sites that previously bypassed it with inline option objects (setupGitHubState, finalizeWorkflow's core-check update) were refactored to route through it too, so every check-creation path in pr-workflow.ts shares one gate.
• postChecks resolves with the same enforced-baseline precedence already used for runnerConcurrency/auxiliary-model settings in initializeWorkflow: org base config (via base-config-path) wins over the repo's own warden.toml, which wins over the post-checks action input default. This matters because it's the same class of workflow-level (not per-trigger) setting, and a repo-level override should not be able to silently defeat an org-wide policy set via the base config.
• ActionInputs.postChecks is non-optional (unlike the default-false booleans requestChanges/failCheck) because its default is true and gets resolved at parse time rather than deferred to each call site — the opposite polarity needs the default applied once, explicitly.

Verification

Applied this change to a local fork (babylist/warden) and verified it against real PRs in a downstream consumer repo before opening this PR:

• With post-checks unset (default true): unchanged existing behavior — checks and comments both post, as today.
• With post-checks: false: confirmed via the GitHub API that no warden / warden: <skill> check runs were created on the PR, while a PR review comment still posted for a real finding.
• With post-checks: true set explicitly at the repo level (overriding an org base-config default of false): confirmed the full check-run set (core + every configured skill) was created again, alongside the review comment.

Also added regression tests exercising postChecks: false end-to-end through runPRWorkflow (both legacy run mode and report mode) asserting checks.create/checks.update are never called while pulls.createReview still is, plus config/schema tests for the warden.toml override and its precedence against the org base config.

pnpm lint && pnpm build && pnpm test all pass (two unrelated, pre-existing flaky tests in cli/files.test.ts/cli/output/jsonl.test.ts fail only under full-suite parallel load and pass in isolation — not touched by this change).