Per-session enabledPlugins overlay (or COPILOT_ENABLED_PLUGINS env var)

### Problem

GitHub Copilot CLI reads `enabledPlugins` from a single global file at
`~/.copilot/settings.json`. Running two CLI sessions concurrently in
different repositories — a common case for engineers who keep multiple
project directories open — causes them to clobber each other's
`enabledPlugins`:

1. Session A starts in `/home/me/dev/projA`, the resolver writes
`enabledPlugins: { projA-plugin: true, projB-plugin: false }`.
2. Session B starts in `/home/me/dev/projB`, the resolver writes
`enabledPlugins: { projA-plugin: false, projB-plugin: true }`.
3. Both sessions function correctly because each loaded its plugins at
startup *before* the other session wrote.
4. The user runs `/restart` in Session A → the CLI re-reads
`settings.json` → loads `projB-plugin`, not `projA-plugin`.

This is structurally unavoidable from outside the CLI: there is no
per-session overlay, and `pluginDirectories` on the SDK
`session.create`/`session.resume` RPC (added in 1.0.55) is not exposed
to shell-launched `copilot` invocations.

### Proposal

Pick one of:

**Option A — Per-session settings overlay.** When the CLI knows its
`session_id`, additionally read
`~/.copilot/session-state//settings.json` (if present) and
merge it on top of the global `~/.copilot/settings.json`. Reconcilers
write the per-session file; the global file is never clobbered by
per-cwd activation decisions.

**Option B — Environment-variable override.** Honour
`COPILOT_ENABLED_PLUGINS=plugin-a@mkt,plugin-b@mkt` for the lifetime of
that invocation. The session's reconciler can compute the right set in
its launcher and pass it in, instead of writing to the global file.

**Option C — CLI flag.** `copilot --enabled-plugins=a@mkt,b@mkt`.
Same semantics as B but more discoverable.

Either A or (B + C) would let third-party tooling (e.g. workspace
managers, monorepo activation scripts) avoid the global-clobber
pattern.

### Why we want this

We ship a per-cwd plugin activator that picks a different plugin set
depending on which project the engineer is working in. It works fine
in single-session use but the cross-session clobber surfaces as
"my plugins disappeared after /restart" support tickets. We have a
warning-only mitigation in our reconciler, but there is no
deterministic fix from outside the CLI.

### Workaround today

We tell users to run all but the primary session with
`pluginResolver.mode: advisory` (a setting our reconciler reads, which
makes it log-only). This works but is bookkeeping the user shouldn't
need to do.

### Related

* Atomic writes for config/settings (shipped in 1.0.56) — solved torn
writes; the last-writer-wins semantics for `enabledPlugins` remain.
* `pluginDirectories` on `session.create`/`session.resume` RPC (1.0.55)
— solves it for SDK clients but not for shell users.

### Acceptance / how we would consume it

If A ships, we drop our reconciler's global writeback and write per
session. If B/C ships, we set the env var (or pass the flag) from our
session launcher. Either eliminates the race for our users.

Start by tracing how the shell-launched copilot command reads ~/.copilot/settings.json and how session.create/session.resume handle pluginDirectories. Compare the proposed session-state//settings.json overlay, COPILOT_ENABLED_PLUGINS, and --enabled-plugins approaches against the existing configuration flow. Done means concurrent sessions and /restart retain their own enabledPlugins without global writeback clobbering.

索引モデルが issue の本文から書いたものです。