Investigate Pi lifecycle integration and completion notifications

Investigate an opt-in Pi extension for structured Canopy agent activity and a completion ping/desktop notification. Keep Pi's ordinary terminal UI; do not infer activity from output, titles or silence. Inspect installed Pi lifecycle hooks and existing Canopy pane/session/service seams, identify a small first milestone and clarify foreground/background/window-closed notification expectations before implementation. Constraints: no prompts, tool arguments, responses or credentials in notification payloads/layout persistence; local bounded same-user IPC if used; distinct cancellation/error outcomes; no active Canopy or session-service restart, protocol migration or user configuration changes during investigation. Acceptance: source-backed recommendation for lifecycle hook, transport/session association, notification policy and compatibility/testing limits. Implementation and runtime validation are separate follow-up scope. Source-verified findings: installed Pi documents agent_settled as the notification-only final idle event after retries/compaction/queued continuations; agent_end is not final idle. AgentSettledEvent includes aborted, while agent_before_settle/turn_end expose completed/aborted/error outcomes. ui_prompt_start/end explicitly identify blocking extension UI, not arbitrary textual questions. Pi's examples/extensions/notify.ts already emits OSC 777 on settlement. Kwi's consumed LGPL Session library decodes terminal notifications and emits notificationRequested(title, body); RemoteSession feeds streamed output through that same Session::feed path, so an attached GUI can consume notifications without a new service wire message. Canopy currently has no desktop notification consumer. Terminal events inherently identify their pane; arbitrary terminal programs can emit them, so they are not authenticated Pi agent-status evidence. Recommendation: first milestone can use an opt-in Pi notification extension with fixed non-sensitive text, skip user-aborted success pings and distinguish errors, plus Canopy notificationRequested handling with bounded plain-text payloads, rate limiting, a KDE/desktop notification and optional desktop-configured sound. Suppress intrusive alerts while the originating pane is actively viewed; keep a per-pane unread attention marker and a show-pane action. This minimal route needs no daemon restart/protocol change and covers Pi launched inside shells once the extension is loaded. For trustworthy structured working/needs-input/settled status, use a small versioned local event channel with same-user checks and per-launch pane/session association, inherited by shells; do not reinterpret generic OSC notifications as structured agent events. Window-closed notification delivery is a separate explicit scope choice: GUI-only handling cannot notify while detached, and old terminal snapshots must not replay stale notifications. Daemon-owned event retention/delivery or a separate background notifier would need compatible lifecycle design, deduplication, desktop D-Bus context and notification activation routing. Newly supplied environment cannot retrofit already-running PTYs. No active service/window restart, code edit, extension install, runtime test, model request or user-config modification occurred. Investigation is source-only; recommend asking whether closed-window delivery is required before implementation.