[Bug]: Settle offered for Done threads archived on owner; invalid saved credential surfaces as generic permission error#23868

Summary

On stable 0.1.2, the web client offers Settle for two Done threads that are already archived on their owning server. Clicking it produces a generic connection-permission error. Connection diagnostics separately reveal an invalid environment credential.

Observed behavior

1. Open the web client with a previously saved direct connection to a remote environment.
2. Two threads are displayed as Done, and the UI offers Settle.
3. Attempt to settle either thread.
4. The toast reads:

The environment's connection diagnostics show:

Independent server verification

• The owning environment still exists and is reachable through a separate operator connection.
• Its environment identity matches the environment targeted by the affected browser routes.
• Both threads can be read directly on that owning server.
• Both are completed and already archived, with no active run and zero pending requests.
• A native settle attempt against the owning server rejects with Thread <redacted> is archived.
• The installed server-side CLI reports 0.1.2. The browser's displayed host version may be cached; this discrepancy alone does not establish incorrect routing or a running-server version mismatch.

Expected behavior

• Clearly explain that the saved connection credential is invalid and provide a discoverable re-pairing/recovery path, rather than only saying the connection cannot change threads or projects.
• Reconcile the threads' archived state when an authenticated connection is restored.
• Avoid presenting a Settle action as usable when the connection cannot authenticate, and avoid offering lifecycle actions that cannot succeed for the thread's reconciled state.

Scope and limitations

The screenshot confirms the browser authentication failure. The independent server checks confirm that the threads exist and are archived. They do not prove that the browser has a healthy authenticated session, that the client knows the current archived state, or that a stale-state bug persists after re-pairing. A clean deterministic reproduction and the result after fresh pairing are not yet available. No claim is made that authorization checks should be bypassed or that archived-thread settlement must be permitted.

Relationship to earlier reports

This was initially added as an anonymized follow-up to #21298, which had already been closed as a duplicate of #4852 before our evidence was posted. Our threads are Done and archived on their owning server; they are not threads stuck Working on a removed host. Nevertheless, the invalid browser credential could share the broader unavailable-environment limitation. That distinction needs verification rather than assuming either a different root cause or an exact duplicate.

The closing discussion on #4852 also explicitly says that lifecycle actions still requiring reconnection remain unresolved and asks for a separate issue covering that part.

Julius: please verify this specific evidence and the scope of any proposed duplicate before taking action, particularly before closing or merging this report as a duplicate. If another issue covers this exact authentication/recovery and archived-state behavior, please identify it and explain the overlap. We are not claiming a distinct root cause solely because the threads show Done instead of Working.

Privacy

This report intentionally excludes deployment URLs, addresses, environment names, thread and project identifiers, credentials, trace IDs, screenshots, and private logs.