remote: no account-wide device list — pairing, revocation, and push targets are all per-Host

Comienza con docs/specs/remote-security-model.md, su elemento Revocation propagation y las convenciones de spec-lifecycle en AGENTS.md. Lee las referencias de ACL y push en lib/src/remote/host/acl.ts, server-lib-common/src/security/acl.ts, lib/src/remote/host/alert-push.ts y docs/specs/server.md. Se considera terminado cuando se registre bajo ## Future un diseño acordado de dispositivos y revocación para toda la cuenta, preservando la autoridad de Host y conciliando las afirmaciones sobre server-label.

No account-wide device list — pairing, revocation, and push targets are all per-Host

Surfaced while making the remote UX account-centric on the push-notifications
branch. Nothing is broken; this is a ceiling that work ran into and deliberately
did not raise.

The goal there was: account-centric user experience over a device-centric
security model. The user thinks "my account, my devices"; the crypto stays
per-device. Most of that landed — signing in on any browser profile with a
synced passkey is now enough to ask to pair, and one phone's two Client
identities (Safari tab vs Home Screen install) label themselves so they can be
told apart. What did not land is the part that actually needs a design decision.

What is awkward today

There is no place that answers "which devices can reach my machines?" Everything
is scoped to a single Host:

• Each Host keeps its own ACL in webview localStorage (lib/src/remote/host/acl.ts,
  HostAcl in server-lib-common/src/security/acl.ts). Nothing aggregates them.
• The Alarm settings dialog can only name devices this machine approved, which
  is why its copy says "paired with this machine" rather than implying an
  account-wide list (lib/src/components/AlertSettingsDialog.tsx).
• Push targets inherit the same scoping: the Host names recipients from its own
  active ACL records (lib/src/remote/host/alert-push.ts).
• Revoking a device means doing it on every machine, by hand — see
  docs/specs/server.md Guardrails, and the already-staged
  Revocation propagation item in docs/specs/remote-security-model.md
## Future.

With one laptop this is invisible. With two or three it means there is no answer
to "I lost my phone, cut it off" short of visiting each machine.

Why this is filed rather than fixed directly

It is not a UX change. docs/specs/remote-security-model.md is explicit that the
ACL lives on the Host and never on the Server, and that the Host is the final
authority for access decisions. An account-wide device list needs device state
the Server can serve, which is a deliberate change to the trust model's storage
story — not something to slip in behind a settings screen.

The questions that have to be answered first:

1. Can the Server hold a device directory without becoming an authority?
   A read-model of identities and labels that every Host still overrides would
   preserve "the Host makes the final decision" — but note the Server today
   deliberately never learns a device label, and both push read routes are built
   so it cannot (GET /api/push/devices, GET /api/push/subscriptions return
   identities only). Putting labels on the Server reverses that choice.
2. Or should the account view be assembled client-side, by asking each Host
   for its ACL? Keeps the Server ignorant, but only shows machines that are
   online, which makes "cut this phone off everywhere" unreliable in exactly the
   situation you would use it.
3. Is this the same project as Revocation propagation? That item already
   stages a Server → Host revocation path. A device list you cannot act on is
   half a feature, and a revocation path with nowhere to see your devices is the
   other half. They probably want one design, not two.
4. What is the identity a user manages? One phone can legitimately be two
   Clients with separate device keys, and they cannot be merged — they are
   separate delivery targets for push. Does the account view group them, and if
   so on what evidence?

Suggested directions

• Answer (3) first. If these are one project, design them together and record it
  as a single named scope under ## Future in
  docs/specs/remote-security-model.md, per the spec-lifecycle conventions in
  AGENTS.md — that spec already owns the revocation item.
• Whatever shape it takes, keep the invariant that a Host's ACL decides access.
  A Server-held directory should be able to inform and request, never grant.
• If a Server-held directory is chosen, decide explicitly whether labels move
  there, and update the "the Server never learns a label" statements in
  docs/specs/server.md and docs/specs/remote-security-model.md rather than
  leaving them contradicted.

Severity: low — no user-visible breakage, and single-machine setups never notice.
It becomes real with more than one Host, or the first time someone needs to
revoke a lost device.