Give the seated user the TPM, so nobody has to join the tss group

ADR 0007 decision 4 refused this a commit ago, on the grounds that widening
access to the machine's TPM is a system-wide decision an application package
should not make for an administrator. That refusal is overturned here, and the
reasoning it is replaced with is narrower rather than louder — because the
refusal had treated "widen access" as one thing when it is two.

Adding a person to `tss` is what the refusal was really about, and it stays the
wrong answer: permanent, effective over SSH, applying whether or not they are at
the keyboard, and needing an administrator and a fresh login before the feature
appears at all.

Tagging /dev/tpmrm0 with `uaccess` is a different thing. It is systemd's own
mechanism for this exact question — the one /dev/dri, webcams, scanners and FIDO
keys already use — and logind grants the ACL to the user of the *active local
session*, then takes it back when that session ends. Not over SSH, not on an
inactive VT, not to daemons. The rule changes neither the mode nor the group, so
everything that worked before still works and the ACL is layered on top.

tpmrm and never tpm, which is what makes it defensible at all: /dev/tpm0 is the
raw device and is exclusive, where /dev/tpmrm0 is the kernel's resource manager,
which virtualises handles and isolates callers precisely so that more than one
unprivileged program can use the chip.

◆ THE COST IS A DENIAL OF SERVICE AND NOT A DISCLOSURE, AND IT IS WRITTEN DOWN.

TPM objects are protected by their own auth values, so this lets nobody read
anybody else's sealed data. What it allows is *failed* attempts — and a TPM
answers enough of those by locking out everyone, which is the same anti-hammering
this project relies on to make a four-digit PIN safe. On a machine that unlocks
its disk with the TPM at boot, somebody sitting at it can trip that and stop the
next boot from unlocking until it recovers.

An administrator who does not accept that masks the file:

    sudo ln -s /dev/null /etc/udev/rules.d/71-dodossh-tpm.rules

which is the standard override, survives upgrades, and puts DodoSSH back to
behaving as though the machine had no TPM. That is in the rule's own comments,
because the person who needs it is reading the file rather than the ADR.

Numbered 71 because 60-tpm-udev.rules is what creates the node's ownership and
73-seat-late.rules is what turns the tag into an ACL; verified in that order on
Fedora 44, along with `udevadm verify` accepting the file and the mask being
reported as "masked by previous entry". %post reloads and replays it against the
tpmrm subsystem, because a rule that waits for a reboot is a feature that does
not work on the day it is installed.

Both channels install the same path deliberately: this is about the machine's
TPM rather than about either build, the file is byte-identical from both, and
giving each its own copy would mean removing one package silently revoked the
other's access.

Phase 19 grew a check that the ACL exists for the local session and does *not*
exist for an SSH one, and another that masking the rule really does put the
machine back — then tells you to undo it before the checks that follow.

Also recorded, after it cost five confusing failures: swtpm serves exactly one
client, so a shell readiness probe sitting on the port makes the whole device-key
suite fail with "The TPM closed the connection" and nothing pointing at why.

docs/adr/0007-device-key-protection.md

@@ -139,13 +139,39 @@ not claimed anywhere in the interface**, which is why `DesktopDeviceKeyStores` d
 why the prompt is deliberately plain rather than dressed to look like a system dialog — teaching people
 that a convincing DodoSSH PIN box is a system dialog is the one thing this design must not do.
 
-**Availability is narrower than "the machine has a TPM", and that is a deployment fact rather than a bug.**
-On Fedora `/dev/tpmrm0` is `root:tss` mode 0660 and desktop users are not in `tss`, so the ordinary case is
-a working TPM this process may not open. That reports unavailable and the passphrase path continues,
-exactly as a machine with no TPM does. **Shipping a udev rule to widen it is refused**: granting every local
-desktop user access to the machine's TPM is a system-wide security decision, some distributions restrict it
-deliberately, and an application package has no business making it on the administrator's behalf. One line
-of `usermod` is the answer, and the README says so.
+**Reaching the TPM at all is the other half, and the package now arranges it.** On Fedora `/dev/tpmrm0` is
+`root:tss` mode 0660 and desktop users are not in `tss`, so without help the ordinary case is a working TPM
+this process may not open — which reports unavailable and keeps asking for the passphrase, exactly as a
+machine with no TPM does.
+
+◆ **This originally said shipping a udev rule to widen that was refused, on the grounds that it is a
+system-wide decision an application package should not make. That refusal was overturned deliberately, and
+the reasoning it was replaced with is narrower rather than louder.** The refusal treated "widen access" as
+one thing. It is two, and they are not close:
+
+- *Adding a person to `tss`* is what the refusal was really about, and it remains the wrong answer. It is
+  permanent, it applies whether or not they are at the machine, it applies over SSH, and it needs an
+  administrator and a fresh login before the feature appears at all.
+- *Tagging `/dev/tpmrm0` with `uaccess`* is the mechanism systemd already uses for `/dev/dri`, webcams,
+  scanners and FIDO keys: logind grants a POSIX ACL to the user of the **active local session** and removes
+  it when that session ends. Not over SSH, not on an inactive VT, not to daemons. `build/linux/71-dodossh-tpm.rules`
+  is that one line, and it changes neither the mode nor the group, so anything that worked before still does.
+
+**`tpmrm` and never `tpm`, which is what makes it defensible at all.** `/dev/tpm0` is the raw device and is
+exclusive; a process holding it can leave the chip in a state that breaks every other user. `/dev/tpmrm0` is
+the kernel's resource manager, which virtualises handles and isolates callers — it exists *because* the TPM
+is meant to be usable by more than one unprivileged program. Granting a seat's user the manager is the use
+it was designed for.
+
+**The cost is a denial of service and not a disclosure, and it is stated because it is easy to miss.** TPM
+objects are protected by their own auth values, so this lets nobody read anybody else's sealed data. What it
+does allow is *failed* authorisation attempts — and the chip answers those by counting them and eventually
+refusing everyone, which is the same lockout decision 4 relies on. On a machine whose disk is unlocked by
+the TPM at boot (`systemd-cryptenroll`, Clevis), somebody sitting at it can trip that lockout and stop the
+next boot from unlocking until it recovers. An administrator who does not accept that masks the file with
+`ln -s /dev/null /etc/udev/rules.d/71-dodossh-tpm.rules`, which is the standard override, survives upgrades,
+and puts the behaviour back to the passphrase-only path. The rule says so in its own comments, because the
+person who needs to know is reading the file rather than this document.
 
 **What was rejected, and why each would have failed the amendment above.** The Secret Service API —
 gnome-keyring or KWallet — is out of process and OS-managed and has *no per-use consent*: once the session