Split ipc.rs into ipc/ by concern, and fix a stale README

Codebase modularization, requested directly. Surveyed the whole
workspace first: at ~38k lines it's already organized by topic
(crates/core/src/manager/, crates/wayland/src/{state,udev,decoration}/
already split into small per-concern files) - crates/platform/src/
ipc.rs was the one real outlier, 1894 lines holding the socket
lifecycle, every payload type, both dispatch match statements, and its
own tests all in one file.

Split into ipc/{mod,types,dispatch,tests}.rs by concern, matching the
established pattern exactly - mod.rs keeps IpcServer itself, types.rs
the response/event structs and snapshot functions, dispatch.rs
handle_request/handle_set, tests.rs the existing suite moved verbatim.
Extracted via exact line-range copies against git's own HEAD content
(not retyped), specifically to rule out a transcription bug in a file
this central. Pure reorganization: build/test/clippy clean before and
after, exact same test count (29 in crates/platform) both times.

README.md separately corrected: it still linked to legacy-cpp/ (deleted
this shift) and described the Wayland backend as the smaller, less-done
one - backwards from current reality, where Wayland is the daily-driver
target and by far the more complete backend.

1 files changed, 12 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index 959df49..d06cc54 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -26,6 +26,18 @@ All of the above is also already documented in `docs/DEFAULTS.md`. Nothing here
 
 **One real, researched-not-guessed gap, left unverified rather than blind-fixed**: `likely_draws_own_titlebar` (`crates/core/src/window.rs`) - the heuristic that force-disables server-side decoration for an app known to draw its own regardless of xdg-decoration negotiation - only matches `org.gnome.*` app ids today. Real web research (Chromium's own issue tracker and Ozone/Wayland mailing list) confirms Chromium's Wayland decoration support has a documented history of being less consistent than Firefox's/GTK's own - specifically, "Chrome shouldn't include decoration insets... when the 'use system title bar' setting is off", and Chromium's own xdg-decoration request-side support has shipped unevenly across ozone/Wayland versions (Lacros added real support; mainline `chromium`/`google-chrome` on Linux has had open issues in this exact area). If a real installed Chrome/Chromium negotiates the protocol correctly and requests `ClientSide` when appropriate, `request_mode`'s existing logic already handles it with no change needed - but if it instead accepts whatever server-side offer it's given while *still* drawing its own frame internally (the same class of bug Firefox needed a fix for), Chrome would show a double titlebar today, uncaught. Not fixed blind: forcing `decorated = false` unconditionally for `chrome`/`chromium`/`google-chrome` would be *worse* than doing nothing if Chrome actually handles `ServerSide` correctly (it would strip a titlebar Chrome was never drawing its own copy of). Needs a live check with a real installed Chrome/Chromium - screenshot it, look for a double titlebar - before this heuristic list grows.
 
+## Codebase modularization: split the one genuinely monolithic file (2026-08-27)
+
+Asked directly to modularize the codebase. Surveyed first rather than guessing where: at ~38k lines across the workspace, the codebase is already organized the way `crates/core/src/manager/` and `crates/wayland/src/{state,udev,decoration}/` already show (one topic per file, a slim `mod.rs`), and most individual files are a few hundred lines. `crates/platform/src/ipc.rs` was the one real outlier - 1894 lines, a single flat file holding the socket/connection lifecycle, every response/event payload type, both dispatch match statements, and its own test suite all at once, unlike every other multi-concern area of this codebase.
+
+Split into `crates/platform/src/ipc/` by concern, matching the established pattern exactly:
+- `mod.rs` - `IpcServer` itself (socket lifecycle, the subscribe-broadcast poll loop). What callers outside this module see (`pub use ipc::IpcServer` in `lib.rs`) is completely unchanged.
+- `types.rs` - every response/event payload struct plus the snapshot functions that build them from `WindowManager`.
+- `dispatch.rs` - `handle_request` (every query/dispatch `cmd`) and `handle_set` (the `"set"` cmd's own sub-dispatch).
+- `tests.rs` - the existing test suite, moved verbatim.
+
+A pure reorganization, not a rewrite: extracted with exact line-range copies (verified against the original file via `git show HEAD:...`, not retyped) rather than reproduced from memory, specifically to rule out a transcription bug in a file this central. Confirmed zero behavior change the only way that actually proves it: build/test/clippy all clean before and after, with the *exact same* test count (29 in `crates/platform`) both times, not just "still green".
+
 ## Global menu research: confirmed current/correct, no newer protocol to catch up to (2026-08-27)
 
 Asked directly to research the global menu further. Real web research (KDE's own source tree at `lxr.kde.org`, current as of Plasma 6.6.5/2026) confirms `com.canonical.AppMenu.Registrar` + dbusmenu - what `crates/platform/src/appmenu_registrar.rs`/`crates/wayland/src/appmenu.rs` already implement - is still the current, unreplaced mechanism in KDE Plasma 6, not a legacy protocol superseded by something newer. Also confirmed: generic (non-Plasma) Qt apps export via `QGenericUnixTheme`'s own registrar-based path since Qt 5.7, matching exactly the real-world case (a Qt app running under srdwm, not under Plasma itself) srdwm's implementation targets. No code gap found - srdwm's own scope here (discovery/registration: which app owns which menu, over D-Bus and the X11/gtk-shell property paths) is already complete and correctly split from AGS's own scope (rendering the discovered menu's real content, a `Gtk.PopoverMenuBar` built from the app's `GMenuModel`) - see `docs/FEATURE_GAP.md`'s own AGS/srdwm scope line.