[FEATURE] Scheduled-task tools expose no link between a taskId and the session(s) that executed it

Problem

mcp__scheduled-tasks__list_scheduled_tasks returns each task's taskId, lastRunAt, nextRunAt, etc. Session-listing tools (list_sessions / the CCD session-mgmt MCP) return sessionId, title, cwd, lastActivityAt — but nothing ties a given scheduled-task run back to the specific session it executed in.

In practice, a session's title is often overwritten by whatever the user works on afterward in the same workspace (these are long-lived, non-git "workspace" sessions), so by the time you go looking, the session that ran a given routine may no longer even be titled after that routine.

Impact

I run a weekly meta-review routine (revue-skills-hebdo) that reads the last 7 days of transcripts for each active scheduled task to detect friction patterns. Since there's no taskId → sessionId link exposed, I have to infer the mapping heuristically every week: match cwd to the routine's workspace, match title to the routine's display name, and match lastActivityAt to the routine's schedule/time-of-day. This is fragile — this week one session was initially misidentified as pure unrelated manual work because its title had been overwritten, and the actual routine session (still running) had to be found separately.

Request

Expose, either on list_scheduled_tasks or on the session listing, something like a lastRunSessionId (or a scheduledTaskId field on session objects) so a session that resulted from a scheduled-task firing can be traced back deterministically instead of via cwd/title/timestamp heuristics.

Context

Windows desktop app. Related but not duplicate: #76103 (let routines set their own session title) addresses a symptom of the same underlying gap (no durable task↔session identity) but wouldn't by itself solve programmatic lookup — a renamed session title still wouldn't be machine-matchable to a taskId.