Taskbar presence card stays at taskState 0 (spinner) when a turn ends via task_complete

Describe the bug

On Windows, the taskbar App Task created by the taskbar-presence feature never leaves the "working" state when a turn ends through the task_complete tool (autopilot mode). The card keeps spinning indefinitely until the session unmounts or the CLI exits.

The 0 -> 1 state transition appears to be wired only to the session.idle event handler (the same handler that maps an aborted turn to state 3). Turns that terminate via task_complete do not appear to emit session.idle, so no handler fires and the task is orphaned at taskState: 0. dispose() on unmount ends up being the only thing that clears it.

Affected version

GitHub Copilot CLI 1.0.84

Steps to reproduce the behavior

1. Enable taskbar presence on Windows 11 (build 26100+) with package identity present (taskbarPresence on, TASKBAR_PRESENCE flag on).
2. Run a session in autopilot mode so the turn ends with the task_complete tool.
3. Watch the taskbar card after the final answer has rendered.
4. The card is still spinning, showing currentStep: "Working on your request".

Inspect %LOCALAPPDATA%\Packages\<PFN>\SystemAppData\AppTasks\tasks.json:

{
  "title": "GitHub Copilot CLI",
  "taskState": 0,
  "dataJson": { "data": {
    "completedSteps": ["...", "Task complete: <the final answer>"],
    "currentStep": "Working on your request"
  }}
}

The debug log shows the last state=0, template=steps write, then the turn ending with "reason": "task_complete", and no further state update:

[DEBUG] Taskbar presence: updated task {...} (state=0, template=steps)
        "reason": "task_complete"      <- turn ends here
        (no state=1 update is ever written)

A session in the same window that ended normally DID reach state=1, template=summary, so this is specific to the task_complete path.

Expected behavior

At the end of the turn the task should move to taskState: 1 with template: summary, matching the behavior of turns that end normally (which do transition correctly).

Suggested fix: drive the terminal state from the task_complete / turn-ended path as well, or emit session.idle on that path.

Additional context

• OS: Windows 11, build 26200; x86_64; Windows Terminal; PowerShell
• The taskbar-presence pipeline itself is healthy. copilot taskbar-selftest, run under package identity, passes every gate (isSupported, packageIdentity, iconUri, createOrUpdate, findAll, tasks.json) and reports "RESULT: tasks.json written - taskbar presence is working." Its own self-test task is created and removed cleanly, leaving only the genuinely stuck session card behind.

Two secondary papercuts in taskbar-selftest noticed while confirming the above:

1. When invoked through a path that does not carry package identity, it reports misleading failures (packageIdentity: none, createOrUpdate: no task created, findAll: 0 task(s)) rather than detecting the situation and telling you to relaunch through the packaged alias.
2. It always prints [FAIL] featureFlag: TASKBAR_PRESENCE disabled (its own output admits "an ExP assignment is not visible to this command") even when interactive sessions log rollout_flag_enabled=true. This reads as a genuine failure when it is not.

从 taskbar-presence 的 session.idle handler 开始，跟踪 task_complete reason 的 turn-ended 路径。在启用 taskbar presence 的 Windows 上复现，然后检查 tasks.json 和调试日志。完成标准是带有 task_complete 的 turn 使用 summary template 写入 taskState 1，而不是让卡片停留在 state 0。