feat(webchat): separate local interactive serving from headless, and drop the token requirement locally

> 🤖 Generated by the Agentic Engineer

Part of #6457. Depends on the mechanism confirmation.

## Problem

`pkg/svc/webchat/webchat.go` reports `Available == false` without a token, because *"a server cannot
drive the interactive device login"*.

That is correct for a **remote** server and wrong for the common case: `ksail open web` serves the
UI from the user's **own machine**, where the Copilot CLI's stored credentials are right there.
One rule is currently applied to two genuinely different deployments.

## Expected behaviour

Distinguish them:

- **Locally served, interactive user** → use the Copilot CLI's OAuth, no token.
- **Remote or headless server** → token required, exactly as today. This is the case that genuinely
cannot do better, and it is why token support is kept.

The distinction must be made on something honest about the deployment rather than a guess; settling
how to detect it is part of this issue, and if it cannot be detected reliably, say so and keep the
token requirement rather than shipping a heuristic that silently fails open.

## Acceptance criteria

- Local serve + CLI authenticated + no token → assistant available.
- Remote/headless + no token → unchanged; availability still gated, with a message naming the token.
- Token set → unchanged in both.
- The local-vs-remote determination is covered by tests in both states.

Start in pkg/svc/webchat/webchat.go and trace how availability is determined for ksail open web. First establish an honest local-versus-remote signal rather than a heuristic, then cover both deployment states in tests: local authenticated without a token and remote or headless without one, while preserving token behavior.

Written by the indexing model from the issue text.