`tracebloc login` always starts a new device flow, even when already signed in

[LukasWodka]

What happens

tracebloc login always starts a new device flow, even when the machine already holds a
valid session for the target environment. There is no "you're already signed in" short-circuit:
the command requests a fresh device code, prints a URL and a short code, and waits for someone
to approve it in a browser.

tracebloc auth status already knows the answer — it reports signed in (or
Not signed in. Run 'tracebloc login'.) by reading the stored session. So the state needed to
skip the flow is available; login simply doesn't consult it.

In internal/cli/auth.go, runLogin goes directly to requesting a device code. It does read
the existing profile — enough to preserve its active_client_id across a re-login — so it is
aware a session may exist, but that awareness isn't used to decide whether a flow is needed.

Why it matters

On a headless host this is a dead end rather than an inconvenience. A machine that is
already signed in still cannot get through a step that requires a browser, because login
insists on a new approval it has no way to complete. The credentials it needs are already on
disk.

That turns "re-run login to be safe" — a reasonable thing for a script or a runbook to do —
into a hard stop on any host without an interactive browser, even though the session is valid.

Reproduction

tracebloc login --env <env>      # complete the device flow once, interactively
tracebloc auth status            # -> signed in
tracebloc login --env <env>      # -> opens a NEW device flow, does not short-circuit

Expected: the second login recognises the valid session and exits successfully without
requesting a device code.
Actual: a new device code is requested and the command waits for browser approval.

Workaround

Use the existing sign-in directly rather than re-running login — e.g.
tracebloc client create --credential-file <path>, which consumes the stored session and needs
no browser step.

Suggested behaviour

• If a valid session for the target environment exists, login reports it and exits 0 without
  starting a device flow.
• Add an explicit opt-out (--force, or similar) for the case where the user genuinely wants to
  re-authenticate — switching accounts, or replacing a session they believe is stale.
• If the stored session exists but is expired or rejected, say which of the two it is before
  starting a new flow; "not signed in" and "your session expired" are different situations and
  lead the user to different actions.

Notes

Cosmetically related but distinct: a non-interactive login route (an enroll-token style grant)
is already noted elsewhere as a separate follow-up. This issue is narrower — it is about
login not recognising a session it already has, which is a behaviour change rather than a new
grant type.