A proposer fixes a typo: the title and the paragraph, edited in the open and stamped #53

A proposal is written once and can never be corrected. The only doors are propose and withdrawProposal, so a proposer who mistypes a date, names the wrong repository or leaves a sentence half-written has two choices: withdraw the whole thing and lose its thread, or let the group deliberate on text everyone knows is wrong. A group that deliberates asynchronously needs the text to be fixable, and needs to see that it was fixed.

What done looks like

• editProposal(db, who, {id, title, body}) in src/actions.ts: the author only (forbidden, "Only the proposer edits a proposal." — an admin is not an author here, and the README says why), the proposal must be open (invalid — a decided or withdrawn proposal's text is a record), the same length and content validation propose already applies, and updated_at set.
• The options are not editable in this issue, at any door. Changing what people are choosing between after they have chosen is a different thing entirely and needs ballots to reason about; say so in the refusal and in the README, and leave it to a later issue.
• An edit is visible: /p/:id shows "edited" with the time whenever updated_at is later than created_at, next to the proposer's name — never silently. The remark thread is untouched.
• An edit emits proposal.edited so an open page updates in place, through the live region it already has.
• Every door: an Edit link on /p/:id for the author that opens a form pre-filled with the current text (a page of its own or a disclosure on the proposal page — no JavaScript either way), PATCH or POST /api/proposals/:id taking {title, body} through answer, MCP tool edit_proposal, and e in the terminal under the cursor.
• Tests in src/actions.test.ts and src/server.test.ts: a non-author is refused; the author on a decided proposal is refused; an over-length title is refused with the same sentence propose uses; an edit that changes nothing still succeeds and does not stamp a false edit; the page shows "edited" only after a real change; < in the new title is escaped on the page; the event reaches a second process.
• README.md gains two sentences: what may be edited, and that the edit is shown rather than hidden. bun test is green.

Files I expect to change: src/actions.ts, src/actions.test.ts, src/pages/proposal.ts, src/routes.ts, src/mcp.ts, src/tty.ts, src/server.test.ts, README.md.

Risks: the temptation here is an edit history table; do not build one — updated_at and a visible "edited" is what a group of this size needs, and a history is a separate issue with its own page. An edit must not be a way to change the question after a vote: if #5 has landed, refuse an edit once any ballot exists on that proposal and say so in the refusal, and add that test. Keep the option rule absolute, or acceptCounter (#6) and voting will disagree about what the options are.

Fit: Ledger — the text corrected on the record, with the correction on the record too. A person assigns; I do not.