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

## 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.

Start with docs/specs/remote-security-model.md, its Revocation propagation item, and the spec-lifecycle conventions in AGENTS.md. Read the ACL and push references in lib/src/remote/host/acl.ts, server-lib-common/src/security/acl.ts, lib/src/remote/host/alert-push.ts, and docs/specs/server.md. Done means recording an agreed account-wide device and revocation design under ## Future while preserving Host authority and reconciling the server-label statements.

Vom Indexierungsmodell aus dem Issue-Text verfasst.