docs: mechanism, policy and configuration are three things

The phase 2 design called devices.csv "policy". It is not. The CSV is
configuration — declarative data an operator edits. The policy is the
component that decides using it: the device manager matching a device to a
driver, init reading protocol.csv and granting a binding. The kernel holds
mechanism, the check that a grant exists before a mapping is made.

Corrected where the document conflated them, and the three are now tabulated
so the rest of the design can lean on the distinction.

It also sharpens the open question. It was "manifest or not"; it is really
whether the grant list should be configuration from the start, or whether
init should hand the device manager the root grants and let it match by the
devices.csv it already reads. A device-grant file adds a second place an
operator must keep correct, and earns itself only when something needs to
differ from "the manager gets the hardware" — holding a device back for a
test or a bare-metal driver, say.

docs/os-development/device-authority.md

@@ -45,8 +45,16 @@ behaviour. **Closing the hole is what retires the constant**, not a bigger numbe
 - *Move as much responsibility as possible to user space* (3), and *what remains in the
   kernel is there for security or a hardware limitation* (5).
 
-Deciding **which** driver gets **which** device is policy: it reads a CSV, matches
-identity triples, and picks a binary. That is the device manager's, and it stays there.
+Deciding **which** driver gets **which** device is policy — matching identity triples
+and choosing a binary. That decision belongs to the device manager and stays there.
+`devices.csv` is not the policy; it is **configuration**, the declarative data the
+policy reads. Three distinct things, and worth keeping apart in this document:
+
+| | Lives in | Example |
+|---|---|---|
+| **Mechanism** | the kernel | the check that a grant is held before a mapping is made |
+| **Policy** | user space | the device manager matching a device to a driver |
+| **Configuration** | files | `devices.csv`, `protocol.csv`, `init.csv` |
 
 Enforcing that a driver **holds only what it was given** is security — it is the gate in
 front of mapping physical memory. That stays in the kernel, and it is the whole of what
@@ -112,11 +120,17 @@ drivers need that reordering, and it is the bulk of the work.
 responsibility in PID 1, which is a cost worth naming — though the alternative is the
 kernel deciding who may hold what, which principle 5 excludes.
 
-**A configuration question follows.** `/protocol` grants are data (`protocol.csv`),
-because who may speak to whom is policy. Device grants could be too — a manifest saying
-which binary may be given which device class. That would be the natural symmetry, and it
-is *not* proposed here: `init` handing the manager everything and the manager matching
-by `devices.csv` is the smaller step, and the manifest can follow if it earns itself.
+**A configuration question follows.** Who may bind which protocol name is expressed as
+configuration today — `protocol.csv` — with `init` as the policy that reads it. Device
+grants could be expressed the same way: a file saying which binary may be given which
+device class, with `init` again the policy that enforces it.
+
+That symmetry is real but it is *not* proposed here. The smaller step is `init` handing
+the manager the root grants and the manager matching by `devices.csv`, which is
+configuration it already reads. A device-grant file adds a second place an operator must
+keep correct, and it should only arrive when something needs it to differ from "the
+manager gets the hardware" — for example, holding a device back from the manager so a
+test or a bare-metal driver can take it.
 
 ## What it does not solve