feat(notifications): approval kind + handler registry

[alex-fedotyev]

Summary

Adds an actionable approval notification kind to Nerve so cron-filed TAPs surface on Telegram + web as inline Approve / Decline / Snooze buttons instead of plain copy-paste prose. PR 1 of the actionable-inbox series; ships the server-side surface so a follow-up cron-prompt rewrite can route the four urgent TAP action types through it.

What this PR ships

• v028 migration.notifications gains target_kind + target_id columns and an index on (target_kind, target_id). Existing rows are left with NULL target_kind, which the answer-routing code treats as the legacy session-injection path. type=approval is the third valid type value alongside notify and question.
• NotificationStore.create_notification accepts target_kind + target_id. New snooze_notification(id, expires_at) advances the row's expiry while keeping it pending so a later re-delivery tick can surface it again.
• nerve/notifications/handlers.py. Dispatcher registry keyed by target_kind. PR 1 registers one entry, mechanical-action, which shells into <workspace>/scripts/mechanical-action.sh for approve / decline / snooze_24h. Workspace resolves from $NERVE_WORKSPACE_PATH (test override) or config.workspace.
• NotificationService.propose_action(target_kind, target_id, ...). Creates an approval notification, delivers to Telegram with an inline keyboard and to the web with the same approval styling. Option labels live alongside option values so labels can be renamed without changing callback payloads.
• propose_action MCP tool. Mirrors notify / ask_user for callers that want their answer to route through a dispatcher instead of being injected back into the originating session.
• Telegram callback parser + web card wired to the new approval kind.
• 16 backend tests cover schema, store, propose_action shape, the approve / decline / snooze dispatch paths, the no-dispatcher fallback, and confirm the question path still flows through the session-injection branch.
• Code map at notes/repo-conventions/nerve/notifications.md.

Why first

Today the executor cron emits plain [TAP] notifications whose bodies are shell commands. On Telegram that means copy-paste into a terminal; no inline button. ask_user already proves the actionable primitive exists end-to-end (web buttons + Telegram inline keyboard); this extends it to the approval use case so dispatching can happen server-side without needing a live agent session.

Out of scope (follow-ups)

• Executor cron rewrite to file propose_action for the four urgent TAP action types (ci.fix-mechanical, ee.merge-followup, meta.config-edit, github.rebase-pr). Single YAML edit in /root/.nerve/cron/jobs.yaml; tracked separately because it touches the live cron prompt rather than Nerve code.
• Plan dispatcher (target_kind="plan").
• Snooze re-delivery scheduler tick.

Test plan

• pytest tests/test_notifications_actionable.py ; 16 tests pass locally.
• Wider-suite check: 596 / 598 tests pass; the 2 failures are pre-existing env-detection cases in test_bootstrap and test_cli_upgrade, unrelated to this change.
• Fresh-DB migration run: discover_migrations() returns unique versions; run_migrations() advances schema_version to 28 and creates target_kind + target_id columns plus the idx_notifications_target index.
• End-to-end smoke from a separate agent session: propose_action(target_kind="mechanical-action", target_id=<id>, ...) creates an approval notification, delivers to Telegram + web with the inline keyboard, and the dispatcher routes the answer to mechanical-action.sh.