[robertjamesprior]

Summary

Logs the work area a maximized window will actually cover, once per chromium start, at warning level when it is smaller than the display.

Why

A window maximizes into the work area the window manager publishes in _NET_WORKAREA, which is the root minus whatever docked windows have reserved through _NET_WM_STRUT. Nothing inside the browser can see the difference: chromium reports a window maximized into a reduced work area as maximized, at whatever size it was given, and screen.availWidth is the only hint — which is a value almost nobody reads. Today the only way to find out that a browser is not covering the desktop is to watch a screen recording of the session.

This image ships no panel, so the work area should equal the root. When it does not, something in the session reserved the difference, and every maximized window in that session is smaller than the display by that much. That is worth one line.

What it logs

Two bounded X reads, xwininfo -root and xprop -root _NET_WORKAREA, in front of the promotion that already runs once per chromium start:

• equal: display geometry at browser start at info, with the root and work area dimensions.
• smaller: work area is smaller than the display, so a maximized window will not cover it at warn, with the same fields.

A read that fails is not logged. Both commands are bounded, and a window manager that has not published _NET_WORKAREA yet is an ordinary startup state rather than a fault.

Deliberately not a behaviour change

Honouring a strut is correct. A session that puts a banner, a consent strip or an on-screen keyboard on the desktop needs the browser to stay out of that space, and a window that fills the root regardless would cover it. So this reports the mismatch rather than overriding it; if "fill the display regardless of struts" is ever wanted, it belongs behind an explicit session option.

Testing

• go test -race across the non-e2e packages: pass
• go build ./..., go vet ./cmd/api/api/ ./lib/x11/: clean
• New parse tests for _NET_WORKAREA cover a full display, a work area reduced to half, the multi-desktop form (four numbers per desktop), an unset property and a truncated value

The log line itself needs a built image to observe; the parser is covered by the tests above against xprop's documented output.

Follow-up worth having, not in this PR

The same facts belong in a telemetry event, not only a VM log line, so a customer can see them without asking us. That needs an event type in server/openapi.yaml plus the matching type on the API side, so it is its own change.