docs: catch the build docs up with the package split

Review findings: the plan doc claimed no implementation existed, had the
domain dependency order wrong (kernel depends on protocol; device on
kernel + protocol + csv), never placed the three shared contracts, and
named a nonexistent new-driver-checklist.md. Its status now records the
implemented phases (and the deliberate pci-bus-first pilot), the target
shape carries the contract placements and the path-dependency-only
constraint on the kernel package's out-of-root abi export, and the
execution notes describe the post-pilot build for whichever session
runs the remaining waves. README's repo layout gains build-support/
and the packages-note; driver-model, threading, system-requirements,
and the two display plan docs stop citing root build.zig for recipe
facts that now live in build-support.

library/kernel/build.zig

@@ -6,7 +6,10 @@
 //! This package also exports `abi` — the kernel <-> user contract (SystemCall
 //! numbers, mmap prot flags, page_size). Its source lives with the kernel in
 //! system/abi.zig, outside this directory, but userspace's one view of it is
-//! exported here so every consumer names the same module instance.
+//! exported here so every consumer names the same module instance. Reaching
+//! outside the package root means this package is valid only as an in-repo
+//! path dependency (never fetchable by hash) — fine, since path dependencies
+//! are the only way danos packages are consumed.
 //!
 //! The root shim (root.zig) and the user link script (user.ld) are plain
 //! files, not modules; build-support reaches them through this package's