kernel: device_transfer — you may give away what you hold

The mechanism behind delegation, which device-manager.md named as the step
after hello: the device manager claims what discovery seeded and hands each
device to the driver it matched, so assignment stops being
first-come-first-served.

It is a MOVE, not a copy. A claim is exclusive (driver-model.md, invariant
1), so the giver stops holding the device the instant the receiver starts.
That is why this is a new syscall rather than the M13 capability path, where
a passed handle is shared refcounted — exclusivity cannot be expressed that
way.

The kernel's whole rule is that you may give away what you hold. It has no
notion of which task is the device manager and deliberately gains none: a
binary name inside the kernel is not something that cannot safely live in
user space. A recipient that does not exist is refused, because a device
moved to nobody would be unreachable for the rest of the boot — nothing
un-holds a device but task death.

Three errnos, each naming its own rule: ENODEV no such device, EPERM you do
not hold it, ESRCH no such recipient.

Nothing uses it yet. The five claimants move across one at a time in D4-D5,
so the suite stays green throughout and a regression names the driver that
caused it.

Ten assertions, verified to discriminate: removing the ownership check flips
four of them, including the giveaway that an illegal transfer then blocks
the legitimate claim behind it.

Suite 116 -> 117.

docs/bounds-track-plan.md

@@ -39,7 +39,7 @@ that cannot safely run in user space.**
 
 | Step | What | State |
 |---|---|---|
-| D1 | `device_transfer(device_id, task_id)` — the holder gives a device away | not started |
+| D1 | `device_transfer(device_id, task_id)` — the holder gives a device away | **done** — syscall 54; a move, not a copy |
 | D2 | Adversarial case: a process handed nothing is refused, on a held device and a free one | not started |
 | D3 | The manager claims the seeded devices at boot, before any driver is spawned | not started |
 | D4 | `usb-xhci-bus` receives its controller in the `hello` reply instead of claiming argv[1] | not started |