Let the /routines page accept a proposal, gated at step-up (#46)

Accepting a routine gives the trigger loop a new standing reason to speak to
the human, so it is the same authority tier as enabling a tool and shares the
stepUpOK gate; dismiss only ever makes maven quieter, so it is ungated.
Look at handleRoutines and acceptRoutine in cmd/mavweb/main.go: accept creates
the recurring reminder, then links it via the new ipc AcceptProposedRoutine.
The page now says what maven noticed in her own words (pattern.PhraseRoutine).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CGeSZxh1DCtRxmFVSYVGvJ

internal/ipc/api.go

@@ -237,6 +237,11 @@ type dismissProposedRoutineReq struct {
 	ID int64 `json:"id"`
 }
 
+type acceptProposedRoutineReq struct {
+	ID         int64 `json:"id"`
+	ReminderID int64 `json:"reminder_id"`
+}
+
 // CoreAPI — what core exposes to modules. One Go interface, satisfied by:
 //   - the in-process store adapter (server.go storeAPI) — used by the daemon
 //     for modules that live in-process for now (router, delivery) and by tests,
@@ -286,6 +291,9 @@ type CoreAPI interface {
 	ListProposedRoutines(ctx context.Context) ([]ProposedRoutine, error)
 	// DismissProposedRoutine flips a proposed routine to 'dismissed'.
 	DismissProposedRoutine(ctx context.Context, id int64) error
+	// AcceptProposedRoutine flips a proposed routine to 'accepted' and links
+	// the reminder that will fire it. The caller creates the reminder first.
+	AcceptProposedRoutine(ctx context.Context, id, reminderID int64) error
 
 	// TickTrace returns the most recent tick's rule trace. The daemon caches
 	// this after every tick; the store adapter returns an error (trace is not