Spike 2952: Copilot CLI attach-to-issue UX

## Goal

Wire Copilot CLI into the "local sessions on issues" pipeline by letting a CLI session declare it's attached to a specific GitHub issue at session-create time, and surfacing that attachment on the issue header.

Tracking issue: github/planning-tracking#2952

## Context

The spike (planning-tracking#2952) is converging on the **AgentSessionStart hydro pipeline** path (per the [hydro-schemas#8634 pivot comment](https://github.com/github/hydro-schemas/pull/8634#issuecomment-4444339952), discarding the MCP-request-telemetry approach).

What's already in flight in adjacent repos:

- **copilot-mission-control#3311** — accepts `ResourceType: "issue"` on session create. Backend is ready to receive the new resource type. CI green, awaiting reviewers.
- **github-ui#20800** — frontend gating for the CLI session deep-link on the issue header. Cloud-agent behavior preserved; CLI deep-link suppressed unless viewer is the session creator. CI green after lockfile fix.

Neither of those does anything user-visible until the **CLI side** starts attaching sessions to issues.

## Scope

Three pieces, roughly in order:

1. **Attach UX in the CLI**
- Detect or accept the target issue (e.g., `gh copilot --issue OWNER/REPO#42`, or auto-detect from current working context, or a slash-command in-session).
- Resolve the issue's repo + numeric id.
- Pass `resource_type: "issue"`, `resource_id`, `resource_number` when creating the mission-control session (`POST /agent_tasks/sessions` or whatever the current create call is).

2. **Session-lifecycle events carry the issue resource**
- Once a session is attached, `AgentSessionStart` / `Finish` / `WaitingForUser` events emitted by mission-control should already carry `resource_type="issue"` + `resource_id` (see the follow-up listed in copilot-mission-control#3311's body: "Wire the new resource type through `publishSessionHydroEvent`").
- The CLI side just needs to ensure the session attachment is set early enough that the first event carries it.

3. **In-session UX**
- When a session is attached to an issue, surface that in the CLI (a header pill, a status line, a confirmation). Detach UX too.

## Out of scope

- Cloud-agent assignments, unaffected by this work.
- 3P agents (Claude Code, Codex, etc.), separate path, deliberately not lumped in here.
- Multi-issue attach (one session, multiple issues), defer until single-issue is shipped.

## Open questions

- **Attach trigger:** explicit flag, auto-detect from `gh` context, or in-session command? Probably want at least the explicit flag for the first iteration, with auto-detect later.
- **Pre-existing session attachment:** if the user already has a session running and then wants to attach, do we allow re-attachment via session update, or require a new session? `copilot-mission-control#3311` updates the Update path with a NOTE that Issue is not yet handled there; resolving that is a soft prereq.
- **Cross-repo issues:** what if the user attaches to an issue in a repo different from their current working dir? Allowed or rejected?

## Dependencies

- **Not blocked by** copilot-mission-control#3311 merging, CLI work can begin against the draft. But the end-to-end test requires #3311 to be merged.
- **Likely needs** a dotcom-side change to actually create an `AgentAssignment` row when an Issue-typed `AgentSessionStart` event arrives. (See discussion thread on planning-tracking#2952: `HydroSweAgentJobStatusChangeJob` is a notifier, not a creator; the existing creator job `HydroCopilotAgentAssignmentLiveUpdateJob` only handles the `issue_created` automation path, not "CLI attached to existing issue.")

## Status

Draft issue. Not ready to start work until the CLI-attach trigger UX is agreed on. Filing now so the open-PR cluster has a CLI-side anchor.