Polecats: Run quality gates before gt_done to self-validate

[jrf0110]

Parent

Part of #204 (Phase 4: Hardening)

Problem

Polecats currently push their branch and call gt_done without running any quality gates. The first time the code gets validated is when the refinery picks it up from the review queue — which means the refinery is the one discovering lint failures, test breakages, and build errors that the polecat could have caught and fixed itself.

This wastes a full round-trip: refinery reviews → finds gate failure → sends rework request → polecat re-dispatches → fixes → pushes → re-enters review queue → refinery reviews again. If the polecat had run the gates before calling gt_done, it would have caught the issue in-session while it still has full context, fixed it immediately, and submitted clean code to the refinery on the first pass.

Solution

Inject the town's configured quality gates (townConfig.refinery.gates) into the polecat's system prompt and instruct it to run them before calling gt_done.

Polecat prompt changes

Add a "Pre-Submission Gates" section to src/prompts/polecat-system.prompt.ts between the current "Workflow" and "Commit & Push Hygiene" sections:

## Pre-Submission Gates

Before calling gt_done, run these quality gates to validate your work:

1. `pnpm test`
2. `pnpm lint`
3. `pnpm build`

If any gate fails, fix the issue and re-run. Do not call gt_done until all gates pass.
If you cannot fix a gate failure after a few attempts, call gt_escalate with the 
failure output and then call gt_done anyway — let the refinery make the final call.

The gate list is dynamic — populated from townConfig.refinery.gates, same source the refinery uses. If no gates are configured, this section is omitted.

buildPolecatSystemPrompt signature change

Add gates: string[] to the params. The prompt builder formats them the same way the refinery prompt does.

Dispatch change

startAgentInContainer() (or wherever the polecat's system prompt is built) already has access to townConfig for the rig. Read townConfig.refinery.gates and pass them to buildPolecatSystemPrompt.

Acceptance Criteria

• buildPolecatSystemPrompt accepts gates: string[] parameter
• Polecat system prompt includes quality gate commands when gates are configured
• Prompt instructs the polecat to run gates before gt_done, fix failures, and escalate if stuck
• Gates are read from townConfig.refinery.gates at dispatch time (same source as refinery)
• No prompt change when no gates are configured (no empty "run these gates: (none)" section)

Notes

• No data migration needed — cloud Gastown hasn't deployed to production
• This is a prompt-only change + a minor plumbing change to pass gates through dispatch. No new tools, endpoints, or schema changes.
• The refinery still runs gates independently — this doesn't replace refinery validation, it front-loads it. The refinery remains the gatekeeper; the polecat is doing a pre-flight check.
• There's a question of whether polecats should run gates after every commit or only before gt_done. Starting with "before gt_done" is simpler and catches the most impactful case. Per-commit gating could be a follow-up if rework rates stay high.