Add outreach candidate editing controls

docs/frontend.md

@@ -36,6 +36,8 @@ Prepared cards in the authenticated outreach funnel expose the exact opener, gro
 
 The funnel header also offers a destructive, confirmed **Clear funnel** action. Its dialog names the number of cancellable candidates, explains that audit rows remain and running discovery can refill the queue, and separately identifies any in-flight sends that cannot safely be cancelled. Success is reported from the authoritative API response before the funnel query refreshes.
 
+Each non-sending candidate has a confirmed **Remove** action. Prepared candidates in ready or retrying state also have **Edit message**: the modal validates the 1–2000 character limit, the server re-applies outbound safeguards, and a successful edit is shown as operator-authored attribution. Buttons are intentionally absent once the candidate is sending, while the server still enforces the state boundary against stale pages.
+
 ## State model
 
 - Remote state: TanStack Query snapshots parsed by shared Zod schemas.
@@ -63,7 +65,7 @@ Rules:
 - Duplicate/replayed events must be harmless.
 - A disconnected stream marks data stale but does not blank useful cached content.
 - Invalid event payloads are contained and repaired with a snapshot refresh.
-- The notification centre retains useful lifecycle history, including successful syncs. Sticky toasts are reserved for inbound replies/media and attention-worthy failures or runtime/account states; they remain visible until the operator dismisses them.
+- The notification centre and sticky toasts are reserved for inbound replies/media and attention-worthy failures or runtime/account states. Routine sync completions, successful sends, healthy lifecycle changes, and raw logs remain visible in their owning screens instead of creating notifications. Toasts remain visible until the operator dismisses them.
 - Raw technical logs belong in Operations, not as general user notifications.
 
 ## Authentication and privacy