Release 0.16.0: owner-only invite for per-RFC contribution + discussion (+ #21 Part C Amplitude wiring)

Wave 5 / Track B. Roadmap item #12. Folds in #21 Part C Amplitude
wiring inline (operator ask: "best practices from the very get-go").

RFC owners can invite specific users to one of two per-RFC roles:
contributor (open PRs + join discussion) or discussant (discussion
only). Non-invited users keep the v0.6.0 anonymous-read contract.
The per-RFC write gate layers on top of the existing
require_contributor gate; a super-draft with no owners yet falls
through to the platform-granted contract, preserving the
v0.6.0/v0.7.0/v0.8.0 contracts in their domains.

Backend: migration 018_rfc_invitations.sql (auto-applied — two
tables: rfc_invitations + rfc_collaborators); api_invitations.py
with five endpoints + transactional email; auth.py helpers
(is_rfc_owner / is_rfc_collaborator / can_discuss_rfc /
can_contribute_to_rfc / can_invite_to_rfc); api_discussion +
api_branches + api_prs gate composition; api_admin.py additive
rfc_invitations[] per user. 237 backend tests pass (18 new in
test_rfc_invitations_vertical.py).

Frontend: InvitationsModal.jsx (owner surface), AcceptInvitation.jsx
(/invitations/accept route), api.js helpers, RFCView.jsx
Invitations button, App.jsx route registration.

Amplitude wiring (inline, #21 Part C):
  - INVITATION_SENT from InvitationsModal { rfc_slug, role_in_rfc }
  - INVITATION_ACCEPTED from AcceptInvitation { rfc_slug, role_in_rfc }
  - identify() BEFORE the accept event with properties: invited_at
    (setOnce), last_invited_to_rfc, last_invite_role_in_rfc,
    claim_method: 'rfc-invite'
  - EVENTS taxonomy extended with INVITATION_SENT + INVITATION_ACCEPTED

No new secrets, no new overlay keys, no operator gesture beyond the
v0.15.0 overlay-set + restart. Frontend build verified green.

Subagent ν shipped the feature on feature/v0.16.0-owner-invite
(a51beec). Driver-side integration squash-merged into main,
hand-resolved VERSION + package.json + CHANGELOG (strict-descending
0.16.0 → 0.15.0), and added the inline Amplitude wiring.

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

backend/app/api_discussion.py

@@ -116,6 +116,17 @@ def make_router() -> APIRouter:
     ) -> dict[str, Any]:
         viewer = auth.require_contributor(request)
         _require_rfc_readable(slug)
+        # v0.16.0 (roadmap item #12): the per-RFC discussion is now a
+        # gated surface. The platform-level `require_contributor` above
+        # ensures the user is signed in + admin-granted; this layer
+        # narrows further to "is this user named for this RFC?" The
+        # 403 here is structurally the v0.6.0 anon-write refusal
+        # extended to non-invited platform users.
+        if not auth.can_discuss_rfc(viewer, slug):
+            raise HTTPException(
+                403,
+                "This RFC's owner has not invited you to its discussion",
+            )
         cur = db.conn().execute(
             """
             INSERT INTO threads
@@ -175,6 +186,12 @@ def make_router() -> APIRouter:
     ) -> dict[str, Any]:
         viewer = auth.require_contributor(request)
         _require_rfc_readable(slug)
+        # v0.16.0 (item #12): same per-RFC gate as create_discussion_thread.
+        if not auth.can_discuss_rfc(viewer, slug):
+            raise HTTPException(
+                403,
+                "This RFC's owner has not invited you to its discussion",
+            )
         _require_discussion_thread(slug, thread_id)
         message_id = chat_layer.append_user_message(
             thread_id=thread_id,