Request a device link code a human can approve in the console

Mint the two artifacts of one device request (D-X16-O1/O3/O5).

Unauthenticated by design — nobody is signed in on the machine being linked, which is the whole point — so this grants nothing on its own. It writes one pending row that names no node and no account: the node does not exist until a human approves, and the approval runs the same account-standing assertion the console mint runs (D-X16-O25). The most this route can be made to produce in bulk is rows that expire, which is what the budgets above bound.

Both plaintexts exist only in the response object. The row keeps their digests; the audit row keeps neither, and passes both to forbidden_values so that any future edit which interpolates one into the metadata raises here rather than shipping.

Two other things are captured, and the difference between them is the whole of D-X16-O23. The three strings the daemon reports about itself are stored because the approval screen has to show a human something they can recognise their own laptop by — bounded and control-stripped on the way in, and labelled unverified on the way out, because this route is unauthenticated and a phisher writes whatever reads best. The address the request came from is stored because it is the one requester fact the requester cannot choose, and because it can only be observed here: by the time the approval screen loads, the only address the cloud can see is the approver's own.