Release 0.4.0: auto-set RFC owner = proposer

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -23,6 +23,51 @@ skip versions are the composition of each intervening adjacent
 release's steps in order — no A-to-B path is pre-computed beyond
 that.
 
+## 0.4.0 — 2026-05-27
+
+**Minor — no operator action required beyond rebuild + restart.** The
+proposer of a new RFC is now the implicit first owner of its super-
+draft entry, set automatically at propose time from the session user.
+The §13.1 claim flow remains available for *additional* owners. No
+schema changes, no env-var changes, no API-shape changes; only newly
+proposed RFCs receive the auto-owner — existing super-drafts whose
+`owners:` is empty are unaffected and can still be claimed via §13.1
+as before. This is a §19.3 rule-2 spec correction: `SPEC.md` §9.1,
+§9.2, and §13.1 are updated to reflect the new shape.
+
+### Changed
+
+- **`POST /api/rfcs/propose`** (`backend/app/api.py`) now sets
+  `Entry.owners = [user.gitea_login]` when constructing the new
+  super-draft entry, instead of `owners=[]`. The session's
+  `gitea_login` is the canonical source; the endpoint never accepted
+  an owner field from the request payload and still doesn't.
+- **`SPEC.md` §9.1** narrowed: the "no proposed-owner or working-
+  group fields" sentence becomes a proposer-owner-auto / working-
+  group-deferred split, with a §19.3 rule-2 note.
+- **`SPEC.md` §9.2** frontmatter shape: `owners: []` → `owners:
+  [<proposer.gitea_login>]`, with a §19.3 rule-2 note.
+- **`SPEC.md` §13.1** reframed: claim flow is now a graduation-time
+  broadening for additional owners, not a precondition for the
+  proposer's own RFC. The §13.1 / §13.2 / §13.3 graduation pipeline
+  itself is unchanged — the "at least one owner" precondition for
+  graduation still holds and is now satisfied by default.
+
+### Upgrade steps (from 0.3.0)
+
+1. The deployment **MUST** rebuild and restart per the routine
+   deploy steps. No `.env` changes, no schema/migration changes, no
+   API-shape changes.
+2. Operators **SHOULD** note that newly proposed RFCs after the
+   upgrade carry the proposer in `owners:` automatically. Existing
+   super-drafts with empty `owners:` are not migrated; they remain
+   claimable via the §13.1 flow exactly as before. No deployment-
+   side data action is required.
+3. Deployments **MAY** communicate the UX shift to active proposers
+   (the "Claim ownership" affordance no longer applies to your own
+   newly proposed RFC), but the affordance simply hides on RFCs the
+   viewer already owns, so no operator-side action is required.
+
 ## 0.3.0 — 2026-05-27
 
 **Minor — operator action required if a deployment wants to enable the