[Feature]: ChatGPT adapter should support safe per-conversation concurrency

Nobody has claimed this yet.

## Feature Description

OpenCLI's ChatGPT adapter should provide a safe concurrency model for multi-agent workflows, especially when multiple agents use the same Chrome profile and ChatGPT account.

Today, callers cannot reliably distinguish whether a ChatGPT browser-backed command is operating on the intended Project conversation, the active tab, or a shared site context. This makes downstream cooperative locks insufficient, because independent agents can invoke OpenCLI directly.

This issue was originally filed as a bug because the visible symptom was a prompt/response being associated with the wrong ChatGPT conversation. The better long-term framing is an enhancement: OpenCLI needs an explicit target/lease model for ChatGPT conversations.

## Use Case

As an AI-agent user, I want to review multiple GitHub PRs through ChatGPT Project conversations concurrently, so that each PR review stays bound to the correct ChatGPT conversation.

A prompt intended for PR A must never be sent to PR B's conversation. If OpenCLI cannot safely guarantee this, it should fail fast with a clear busy/lease error before mutating browser state.

This matters for long-running ChatGPT workflows where one conversation may keep generating for 10-20 minutes while another agent starts or checks a different conversation.

## Current Behavior / Evidence

Observed on:

- OpenCLI: 1.8.6
- Extension: 1.0.22
- Chrome: 149.0.7827.201
- macOS: 26.5.2

Known observations from E2E testing:

- `ask/send --project --new` can fail or become unreliable while another Project conversation is generating.
- Concurrent browser-backed commands can hit `Detached while handling command`.
- `send --project --new` may return `Status: Success` without a machine-readable `conversationId` / `conversationUrl`, making it hard to prove the message persisted in the intended conversation.
- Sending to a known existing idle conversation can work while another Project conversation is generating, which suggests the problem is not simply "all ChatGPT concurrency is impossible". The unsafe part is that OpenCLI does not expose a reliable target binding / lease contract for callers.

## Proposed Solution

Introduce an explicit target/lease model for ChatGPT browser-backed commands.

Possible shape:

- Bind operations to Chrome profile + ChatGPT site/session + conversation/project target.
- Make `--conversation ` interact only with that exact conversation, or fail before mutation if that cannot be guaranteed.
- Make fresh Project conversation creation return a confirmed `conversationId` / `conversationUrl` after the target is known.
- If the target cannot be acquired safely, fail fast with a typed error such as `CHATGPT_BUSY`, `TARGET_BUSY`, or `DETACHED_TRANSIENT`, instead of implicitly reusing the active tab.
- Expose enough target/session identity for downstream tools to safely run known conversations concurrently while serializing only the operations that truly require exclusive browser state.

The key requirement is correctness: no prompt, response, or follow-up should be able to land in the wrong ChatGPT conversation.

## Alternatives Considered

- Downstream global locks: correct but too conservative. They serialize all ChatGPT work and lose useful parallelism.
- Multiple Chrome profiles: safer but operationally heavy, slow, and inconvenient for normal users.
- Caller-side conversation locks: useful as a workaround, but cannot protect against independent OpenCLI callers.
- Treating this only as a transient detach bug: incomplete, because even when commands do not detach, callers still need a reliable target/conversation contract.

## Non-goals / Separate Issues

This issue is only about safe ChatGPT target/conversation concurrency.

- Renderer CPU/performance is tracked separately in #2095.
- OpenCLI Browser tab group accumulation is tracked separately in #2097 and related tab-group issues.
- Generic CDP multi-instance management is related, but broader than this issue.

## Related History

- #1114 covered same-site concurrent commands detaching each other.
- #1907 covered ChatGPT response/question mismatch.
- #988 tracks broader multi-instance CDP management.

No files, tests, or entry points are named in the issue. Start by tracing the ChatGPT browser-backed command flow and its target selection, then define how exact conversation binding, confirmed IDs or URLs, and fail-fast typed busy errors can be verified. Done means concurrent operations cannot send work to the wrong conversation.

Written by the indexing model from the issue text.