Add the M4 display subplan; amend the parent plan's phasing

The M4 plan defers graphics to a later phase. That is the wrong ordering
for this project -- the desktop is the roadmap, and a machine with a
serial console and no display is not one anybody sits down at. Phase 1 is
complete and m1n1 runs on the target, so the display is the live question.

Costed from first-hand measurement rather than assumption. With m1n1
running as a coih boot object and proxyclient attached, the firmware hands
over 640x1136 -- m1n1's own hardcoded signature for 'iBoot did not light a
real panel' -- and m1n1's attempt to light it itself dies at
rtkit(dcp): did not receive HELLO, with both DCP DARTs reported locked.

Both cheap paths are closed with tests. The apple,simple-framebuffer node
exists and t8132-j773g.dts even pins the HDMI power domains on, but it is
inert unless somebody lit the panel first; and booting via the boot picker
-- which demonstrably lights that same panel -- still yields 640x1136. So
iBoot lighting the display for its own UI and handing a live framebuffer to
a third-party boot object are separate things, and it only does the first.

There is nothing to port: no t8132 in any DCP or RTKit source, no branch,
no open PR, and Asahi's own M4 feature page lists display, HDMI, DCP and
GPU as TBA.

What makes it tractable is where the failure sits -- low, at the RTKit
boot handshake, below endpoints and mode-setting -- and that every layer
beneath DCP already exists under ISC or MIT. The instrument works too:
m1n1's hypervisor was dead on M4 until SPRR/GXF emulation let it load
Apple's SPTM blob, so tracing what macOS does to DCP is available on this
generation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: pkgdemon

nextbsd-apple-silicon-m4-plan.html

@@ -47,7 +47,7 @@
 </head>
 <body>
 <div class="wrap">
-<p class="back"><a href="index.html">&larr; Back</a> &middot; part of <a href="nextbsd-research.html">NextBSD Research</a> &middot; subplans: <a href="nextbsd-m4-boot-footprint-plan.html">the boot footprint</a> &middot; <a href="nextbsd-m4-bench-setup.html">the bench</a> &middot; sibling of the <a href="nextbsd-rpi500-native-boot-plan.html">Pi&nbsp;500+ native boot plan</a> &middot; contrast with <a href="nextbsd-apple-virtualization-plan.html">NextBSD under Apple Virtualization.framework</a></p>
+<p class="back"><a href="index.html">&larr; Back</a> &middot; part of <a href="nextbsd-research.html">NextBSD Research</a> &middot; subplans: <a href="nextbsd-m4-display-plan.html">the display</a> &middot; <a href="nextbsd-m4-boot-footprint-plan.html">the boot footprint</a> &middot; <a href="nextbsd-m4-phase1-runbook.html">Phase&nbsp;1 runbook</a> &middot; <a href="nextbsd-m4-bench-setup.html">the bench</a> &middot; sibling of the <a href="nextbsd-rpi500-native-boot-plan.html">Pi&nbsp;500+ native boot plan</a> &middot; contrast with <a href="nextbsd-apple-virtualization-plan.html">NextBSD under Apple Virtualization.framework</a></p>
 
 <h1>NextBSD on the Mac mini M4: the t8132 hardware map, and the road to a shell prompt</h1>
 
@@ -74,6 +74,11 @@ <h1>NextBSD on the Mac mini M4: the t8132 hardware map, and the road to a shell
 <p>One correction carried from there: the target&rsquo;s 164&nbsp;GB is free <em>inside container <code>disk3</code></em>, not on the disk. <code>resizeContainer limits</code> reports a maximum equal to the current size &mdash; <strong>zero trailing partition-map space</strong> &mdash; so a second container means a live shrink of the only working system on the machine, not an allocation. Measured 2026-08-26; the target has also moved to macOS&nbsp;26.6.2 (25G83) since this page was written.</p>
 </div>
 
+<div class="callout callout-bad">
+<p><span class="pill pill-bad">Amends the phasing &middot; 2026-08-27</span> <strong>This page treats graphics as a deferred phase. That is the wrong ordering for this project</strong> &mdash; the desktop is the roadmap, and a machine with a serial console and no display is not one anybody sits down at. Phase&nbsp;1 is complete and m1n1 now runs on the target, so the display is the live question rather than a later one.</p>
+<p>It has its own subplan: <a href="nextbsd-m4-display-plan.html"><strong>Pixels on the M4</strong></a>. Measured on this machine: iBoot hands a <code>640&times;1136</code> dummy framebuffer to a <code>--raw</code> boot object even when it has just drawn the boot picker on that same HDMI panel, and m1n1&rsquo;s own attempt to light it fails at <code>rtkit(dcp): did not receive HELLO</code>. <strong>No DCP implementation for t8132 exists anywhere</strong>, so this is code to write rather than port &mdash; but the failure sits low in the stack and every layer beneath it is already available under ISC or MIT.</p>
+</div>
+
 <div class="toc">
 <h2>Contents</h2>
 <ol>