Devices: tell same-machine rows apart by origin and key fingerprint

[karngyan]

Closes #71.

What

A Devices screen could list four rows all reading Browser on karn.local, with nothing but a paired-at and a last-seen date to tell them apart. This is the trust model working as designed — the device key is scoped to the browser origin — so the fix is to surface the fact that differs, not to change enrolment:

• The daemon records the Origin header of the enrolment POST on the local registry row (crypto.Device.Origin), carries it on the wire (wire.DeviceInfo.Origin, omitempty), and the Devices row shows it as a place — 127.0.0.1:7719, localhost:7719 — with the scheme dropped.
• Every row shows a short fingerprint: the first six characters of the device id, which is already a digest of the key. This is what tells apart rows that have no origin, e.g. this machine's browser rows as they appear on a sibling machine.

Decisions on the issue's open points

• Hint, not identity. A row with no origin renders as ordinary: no placeholder, no warning. That is the state of every QR-paired phone, every fleet-admitted row, and every row from before this change.
• Local row, not the certificate. The origin is a fact about how this machine was reached; it is never minted into the cert, so nothing about the fleet trust model moves.
• First-seen, not latest. DeviceStore.SetOrigin writes once and refuses overwrites, so a tab that later loads from the daemon's other spelling does not rewrite where it enrolled. One value is enough because enrolment is the only moment an origin is known.
• Older rows backfill themselves. The browser enrols on every page load, so a pre-origin row picks its origin up on its next load; nothing is singled out in the meantime.

Worth knowing: the vite dev server's proxy rewrites Origin to the daemon's own (web/vite.config.ts), so the vite tab records 127.0.0.1:7719 — same as the direct tab. Those two remain distinguishable only by fingerprint, which is part of why the fingerprint ships alongside the origin.

Not in this PR

The issue's secondary suggestions — connected-right-now and a truer last-seen. Loopback sockets carry no device identity (the session cookie is the credential, and wire.Hello names no device), so "connected now" cannot be answered for exactly the rows this issue is about without a protocol change, and it needs its own broadcast machinery. Better as a follow-up.

Tests

• TestSetOriginKeepsTheFirstOrigin (store semantics), TestEnrolRecordsWhereTheBrowserCameFrom (record, wire carry, no-overwrite, backfill).
• Web: rows distinguishable by origin and fingerprint; a row with no origin renders as ordinary.
• Full go test ./..., pnpm vitest run (1465 tests, includes the Tailwind prose-scanner build guard), and pnpm run lint all pass.

🤖 Generated with Claude Code