companion: remove the server bridge and pairing surface

[RaresKeY]

Prerequisites

• I searched open issues, discussions, and PRs and did not find an existing focused removal issue with this scope.
• I checked the merged companion router, pairing code, tests, dependencies, and current consumers on the latest dev branch.
• This is a concrete, actionable proposal: remove the app-specific server bridge after the retained API-token boundary is explicit.

Area

API / Backend

Problem or Motivation

Current dev still registers /api/companion/* and carries a dedicated package for discovery, owner-scoped model inventory, pairing HTML/JSON, LAN address discovery, and QR payload generation. This is an app-specific compatibility surface for a companion client that maintainers have not explicitly agreed to own as a core product.

The open series proposes substantially more companion-only behavior, but retaining even the small merged bridge creates an API and credential contract that must be maintained and secured. The parent tracker #5674 establishes the intended boundary: keep responsive web/PWA support and deliberate generic integrations, but remove the app-specific bridge unless maintainers later make a separate product and architecture decision.

Pairing currently mints an ordinary chat-scoped API token named companion. Those rows are intentionally indistinguishable from tokens created through the normal token system, so this removal must not guess at destructive data migration. The route-capability work in #3149/#3150 should land first so any previously issued token is constrained to explicitly retained API surfaces and can then be revoked through the existing token UI.

Proposed Solution

After the token-capability prerequisite lands, make one focused removal PR that:

• unregisters the companion router from application startup;
• removes the companion package, pairing page/JSON behavior, and companion-only README;
• removes the companion pairing and read-only test suites plus stale test-inventory references;
• leaves generic API-token CRUD, /api/v1/chat, Codex/Claude integration routes, webhooks, responsive UI, and PWA behavior unchanged;
• leaves shared QR support in place because it is also used by core two-factor authentication;
• leaves generic token-owner attribution in place where retained API routes deliberately require it;
• documents the operator path for revoking any old companion-named token without automatically deactivating possibly user-created tokens that share the same name.

Implementation and specification reconciliation should remain separate: land and validate the runtime removal first, then update the relevant documentation/specification surface after the final dev behavior is established.

Acceptance criteria:

• No /api/companion/* route is registered on the resulting application.
• Pairing can no longer mint or display a credential.
• No production or test module imports the removed companion package.
• Generic API-token, webhook, browser, PWA, and two-factor QR behavior remains available.
• Existing token data is not deleted based only on a display name.
• Focused tests cover absence of the removed route and preservation of retained authentication/integration surfaces.
• The branch receives iterative deep review and one clean final exact-head review before publication as a draft PR.

Alternatives Considered

Keeping the read-only endpoints while removing only pairing was rejected because it would preserve an app-specific API contract with no core consumer or maintainer-owned product decision.

Automatically deactivating every token named companion was rejected because the schema does not record token provenance and users can choose the same name for an ordinary token.

Removing generic API tokens, webhooks, responsive web behavior, PWA support, or QR support was rejected because those capabilities have independent core uses.

Expanding the companion bridge while the architecture is undecided was rejected because it increases the surface and migration cost this issue is intended to reduce.

Prior Art / Related Issues

• Parent tracker: companion: remove the app-specific bridge and stabilize token capabilities #5674.
• Token capability prerequisite: Add default-deny API token capability checks for bearer routes #3149, with Harden API token route capabilities #3150 as the existing candidate PR.
• Product-boundary proposal: Proposal: mobile companion app (thin remote) + /api/companion/* bridge #3244.
• Merged bridge history: Companion bridge (1/4): read-only ping/info/owner-scoped models + tests #863, Companion bridge (2/4): token-owner session attribution + tests #871, Companion bridge (3/4): admin-only device pairing (mint on POST, CSRF-safe) + tests #877, and fix(companion): require chat scope for model inventory #4319.
• Companion-specific regressions that become obsolete with this removal: Companion model inventory hides owned endpoints when authentication is disabled #5617/fix(companion): preserve models with auth disabled #5619 and Companion pairing can advertise a container-local host #5618/fix(companion): honor configured pairing address #5620.

Are you willing to implement this?

Yes - I can prepare a focused current-dev removal branch, validate retained surfaces, and open it as a deeply reviewed draft PR.