v0.29.0: #28 Parts 2+3 — create-RFC offers + contribute-to-pending requests

Extends the v0.26.0 (#28 Part 1) read-time scanner into three buckets in
one pass — active link (Part 1), pending-RFC contribute offer (Part 3),
create-RFC offer (Part 2) — precedence active > pending > candidate. The
backend still emits only structured segments (never HTML), so the surface
stays XSS-safe by construction.

Part 2 — create-RFC offers: a multi-word tag from the #27 taxonomy with no
defining RFC renders, for a create-rights viewer, as an inline "+ create
RFC" affordance that opens the propose modal pre-filled (?propose=<term>;
ProposeModal gained initialTitle). Conservative multi-word gate; broader
heuristics + the Haiku path are deferred.

Part 3 — contribute-to-pending offers: a term matching a super-draft
renders, for a signed-in non-owner, an "ask to contribute" affordance with
the owner's display name. It opens a 3-field request form (who/why/optional
use-case); submitting lands a contribution_requests row (migration 024) and
one actionable §15 notification per owner (new kind
contribution_request_on_pending_rfc, personal-direct). The owner's inbox
shows who/why/use-case inline with Accept/Decline. Accept fires #12's
owner-invite flow with the requester as invitee and echoes a notification
back; decline notifies the requester. Pre-merge idea PRs are out of scope.

New endpoints: GET /api/rfcs/{slug}/contribution-target,
POST /api/rfcs/{slug}/contribution-requests,
.../{id}/accept, .../{id}/decline. The invite issue path was refactored
into one reusable api_invitations.issue_invitation(...) chokepoint shared
by the manual invite endpoint and Part 3's accept.

Tests: 9 new (3 scanner-bucket unit + 6 e2e). Full suite 374 passing.

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

backend/app/notify.py

@@ -270,6 +270,86 @@ def fan_out_new_beta_request(
         )
 
 
+def fan_out_contribution_request(
+    *,
+    rfc_slug: str,
+    requester_user_id: int,
+    request_id: int,
+    matched_term: str,
+    who_i_am: str,
+    why: str,
+    use_case: str | None,
+) -> list[int]:
+    """Roadmap #28 Part 3: a reader asked to contribute to a pending
+    (super-draft) RFC. Land one actionable notification per owner and
+    return their ids (the caller stamps the first onto the request row as
+    the inbox-action handle).
+
+    Personal-direct: the owner is the named subject of the request, so the
+    §15.4 email gate consults `email_personal_direct` exactly as for the
+    other owner-facing personal events — no new preference column is
+    needed. The request's three free-text fields ride along in the payload
+    so the inbox row can show the full ask inline without a second fetch.
+    Actor is the requester per §15.9.
+    """
+    requester = db.conn().execute(
+        "SELECT display_name FROM users WHERE id = ?", (requester_user_id,)
+    ).fetchone()
+    display = (requester["display_name"] if requester else None) or "Someone"
+    details = {
+        "request_id": request_id,
+        "matched_term": matched_term,
+        "requester_user_id": requester_user_id,
+        "requester_display": display,
+        "who_i_am": who_i_am,
+        "why": why,
+        "use_case": use_case or "",
+    }
+    notif_ids: list[int] = []
+    for recipient_id in _entry_owner_user_ids(rfc_slug):
+        if recipient_id == requester_user_id:
+            continue
+        notif_ids.append(
+            _emit_one(
+                recipient_user_id=recipient_id,
+                event_kind="contribution_request_on_pending_rfc",
+                category=CATEGORY_PERSONAL,
+                actor_user_id=requester_user_id,
+                rfc_slug=rfc_slug,
+                branch_name=None,
+                pr_number=None,
+                details=details,
+            )
+        )
+    return notif_ids
+
+
+def notify_contribution_decided(
+    *,
+    rfc_slug: str,
+    requester_user_id: int,
+    decider_user_id: int,
+    request_id: int,
+    accepted: bool,
+) -> None:
+    """Roadmap #28 Part 3: tell the requester an owner accepted or declined
+    their contribute request. On accept the requester also receives the
+    #12 invitation email out-of-band; this inbox row is the in-app echo
+    that points them at it."""
+    _emit_one(
+        recipient_user_id=requester_user_id,
+        event_kind=(
+            "contribution_request_accepted" if accepted else "contribution_request_declined"
+        ),
+        category=CATEGORY_PERSONAL,
+        actor_user_id=decider_user_id,
+        rfc_slug=rfc_slug,
+        branch_name=None,
+        pr_number=None,
+        details={"request_id": request_id},
+    )
+
+
 def fan_out_chat_message(
     *,
     actor_user_id: int,
@@ -769,6 +849,16 @@ def render_summary(event_kind: str, actor_display: str | None, rfc_title: str |
         return f"{actor} began graduating {title}."
     if event_kind == "pr_conflict_with_main":
         return f"{actor} started a resolution branch on {title}."
+    if event_kind == "contribution_request_on_pending_rfc":
+        # Roadmap #28 Part 3: owner-facing, actionable. The term is the
+        # super-draft reference that surfaced the offer; the inbox row
+        # renders Accept/Decline beneath this line.
+        term = extras.get("matched_term") or title
+        return f"{actor} wants to contribute to your pending RFC for '{term}'."
+    if event_kind == "contribution_request_accepted":
+        return f"{actor} accepted your request to contribute to {title} — check your email to accept the invitation."
+    if event_kind == "contribution_request_declined":
+        return f"{actor} declined your request to contribute to {title}."
     if event_kind == "new_beta_request":
         # v0.9.0: framework-scoped, not RFC-scoped. The actor (the
         # requester) and the captured full name + email read as
@@ -884,6 +974,11 @@ def list_inbox(
             "read_at": row["read_at"],
             "category": extras.get("category"),
             "summary": render_summary(row["event_kind"], row["actor_display"], row["rfc_title"], extras),
+            # The row's payload, surfaced for kinds that render inline
+            # detail (e.g. #28 Part 3's contribute-request who/why/use-case
+            # + Accept/Decline). Safe to expose: a recipient only ever sees
+            # their own notifications.
+            "extras": extras,
         })
 
     if bundled: