Nucleus 2.6 - #628

Tao is now the single window backend. Removes the three AWT-based modules
(`decorated-window-awt`, `-jbr`, `-jni`) with their native sources, API
dumps, detekt baselines and GraalVM metadata, plus the `jni-demo` sample.

BREAKING CHANGE: `NucleusBackend`, `LocalNucleusBackend`, the `backend =`
parameter of `nucleusApplication`, `NucleusApplicationScope.backend` and
`NucleusWindowUnsafe.awtWindow` / `awtDialog` are gone, as are the AWT
overloads of `MaterialDecoratedWindow` / `MaterialDecoratedDialog` (M2, M3)
and `JewelDecoratedWindow` / `JewelDecoratedDialog` — only the
`NucleusApplicationScope` receivers remain. Compose Desktop's AWT `Window`,
`Dialog` and `Tray` are unsupported; use `DecoratedWindow`, `HostedWindow` /
`HostedDialog` and an AWT-free tray.

- nucleus-application: drops the AWT scope/window/dialog adapters and takes
  `api(project(":decorated-window-tao"))`, since the backend is no longer a
  consumer choice and a missing runtime module would only fail at launch
- material2: ports `MaterialDecoratedDialog` to a `NucleusApplicationScope`
  receiver — it existed only in AWT form, so M2 keeps parity with M3
- removing the AWT overloads also retires the `LowPriorityInOverloadResolution`
  / `INVISIBLE_REFERENCE` workarounds they needed
- taskbar-progress-tao: single Tao dispatch path
- core-runtime keeps `WindowBackend.Awt`: it still describes a plain Compose
  Desktop / Swing host embedding Nucleus libraries
- scheduler-demo moves to Tao (drops the `java.desktop/sun.*` add-opens);
  service-management-demo swaps `java.awt.EventQueue` for
  `rememberCoroutineScope().launch`, as SMAppService completion handlers must
  hop to the Tao main thread
- drops the now-unused `jbr-api` catalog entry, the jni/jbr native build steps
  and verify entries from CI, and rewrites the backend docs
- also adds `rect-stress-demo` / `widget-demo` to `apiValidation.ignoredProjects`
  alongside the other demos, fixing their pre-existing `apiCheck` failures

Compose hardcodes grayscale as the Windows font-smoothing default. Enable
ClearType end to end without runtime reflection:

- plugin: LcdTextDefaultTransform (artifact transform + ASM) patches
  FontRasterizationSettings.PlatformDefault in ui-text-desktop jars on
  non-test runtime classpaths — SubpixelAntiAlias on Windows, opt-outs
  -Dnucleus.text.lcd=false (runtime) / -Pnucleus.text.lcd.patch=false
  (build). Android/HotReload/KMP guards mirror the CleanNativeLibs
  transform; referenced ctor/enum fields are verified so Compose layout
  drift fails the build. Canary test patches both the plugin's Compose
  and the consumer version from the root version catalog.
- tao: lcdSurfaceProps attaches the OS-queried pixel geometry (cached,
  RGB/BGR, grayscale on any unknown) to opaque Windows window surfaces
  only; per-pixel-alpha surfaces (popups, NativeView overlay, Mica or
  Acrylic backdrops, transparent windows) keep unknown geometry so Skia
  falls back to grayscale. renderGlFrame now requires windowTransparent.
- jewel-demo: use JewelDecoratedWindow instead of hand-rolled theming.

DecoratedWindow, DecoratedDialog, HostedWindow and HostedDialog take
androidx.compose.ui.window.v2 state. Requested geometry is applied
asynchronously; observed bounds/placement publish once the window is shown.
tao-demo uses the v2 rememberWindowState and requestPlacement path.

…text

feat(tao): LCD/ClearType text on Windows

WindowState.requestSize()/requestPosition() build the two-arg
WindowBoundsProvider, whose getBounds dereferences an AWT-backed
WindowGeometryProviderScope. Tao has none, so the request was dropped —
but the placement was already rewritten to Floating, knocking a maximized
window out of maximized for a request that never applied. Skip the whole
request when the provider cannot be evaluated, and log it at WARNING
(rememberWindowStateWithBounds hits the same path).

The observed bounds now fall back to the native window rectangle when the
v1 position never turns Absolute: a WM that emits no move event for a
PlatformDefault window left WindowState.isInitialized false and bounds /
size / position throwing forever.

Also: narrow the constantBoundsOrNull catch to NullPointerException so a
provider's own failure is not reported as "needs live metrics"; move
dialog size clamping out of composition into an effect; move
inspectableWindowBounds to dev.nucleusframework.window.tao so apiCheck
covers it and the split package with compose-ui is gone; document that
setMinimumSize/setMaximumSize clear per window, not per axis; register
ComposeWindowV2BridgeTest with the scene test battery drift guard.

Compose v2 documents WindowState.bounds as the whole window, insets
included, but the bridge published the v1 state's outer position paired
with its inner size — so bounds.size changed meaning once the WM emitted
its first move event, and requestBounds(state.bounds) or a
WindowState.Saver restore resized the window by the decoration insets.
Observed bounds now always come from the native outer rect, and the
request path converts back to the inner size the v1 state expects.

Hosts that never expose the TaoWindow (rememberSyncedWindowState) left
isInitialized false forever on a window manager that emits no initial
move, making every bounds / size / position read throw. They now publish
an approximate outer rect instead.

The initial v2 -> v1 conversion drains the request channels, so a window
that left and re-entered composition before ever being visible fell back
to the 800x600 platform default. Memoize the drained geometry per state.

constantBoundsOrNull treated any NullPointerException as "this provider
needs AWT window metrics", hiding real provider bugs behind a dropped
geometry request. Only the shapes that come from the null scope we pass
in count now.

requestSize / requestPosition stay inert: their providers live in a
synthetic lambda's captures, so honouring them would need reflection,
and building a WindowGeometryProviderScope would need a displayable AWT
window. Add requestInspectableBounds() as the working equivalent and
point the diagnostics at it.

Compose 1.12's `androidx.compose.ui.window.v2` is anchored to AWT: `Screen`
wraps a `java.awt.GraphicsDevice` and reads its insets through
`Toolkit.getDefaultToolkit()`, and `WindowGeometryProviderScope` takes a
`java.awt.Window` that must already be displayable. The Tao backend has
neither, so every provider that touches the scope was accepted, logged and
dropped, and `requestScreen` was drained into the void.

Mirror the package instead, member for member, as
`dev.nucleusframework.window.tao.v2`, backed by our own monitor enumeration
and `TaoWindow` rather than by AWT. Migrating is a single import change, and
deleting the package restores the upstream import unchanged if JetBrains
decouples its own types.

- `TaoMonitors` / `TaoMonitor`: multi-monitor enumeration via a new
  `nativeGetMonitors` on each platform bridge (`EnumDisplayMonitors` +
  `GetDpiForMonitor` on Windows, `NSScreen.screens` on macOS, GDK monitors on
  Linux), one tab-separated descriptor per monitor. Physical pixels, top-left
  origin, work area included — the conventions the existing primary-monitor
  calls already used. Never reports zero monitors.
- `v2`: `Screen`, `WindowScreenProvider(Scope)`, `WindowMetrics`,
  `WindowGeometryProviderScope`, `WindowBoundsProvider` /
  `WindowSizeProvider` / `WindowPositionProvider` with their companions,
  `WindowState`, `DialogState`, savers and `remember*` factories.
- `DecoratedWindow` / `DecoratedDialog` / `HostedWindow` / `HostedDialog` /
  `NucleusWindowHost` overloads for the cloned states. The host default
  bodies fall back to the v1 surface, so themed hosts keep working; the
  default host overrides them for the full path.
- Size and position stay split instead of folding into a `DpRect`
  (`CombinedBoundsProvider`): a rectangle cannot carry an unspecified
  position or a wrap-content axis without turning both into `NaN`.
- Wrap-content sizing routes through the window's own path rather than a
  one-shot content measurement, so `Unconstrained` / `PreferredWidth` /
  `PreferredHeight` keep re-measuring.

The Compose-typed overloads stay as they are — best effort with the warning
— and their KDoc now points at the clone.

Verified headfully on a real window (`taoHeadfulTest`, 5 new cases):
initial provider centring, `requestSize` / `requestPosition`, a scoped bounds
provider reading live window metrics, `requestScreen` landing on the target
monitor, and `screenId` tracking the hosting monitor.

Brings the 2.6 line up to date with the released one (#629 MSI installer
options, #630 NSIS menu category, #632 clean-frame present skip, #633
alwaysOnTop stickiness).

Conflict: `nucleus_tao_windows_deco.c` — 2.6's ClearType pixel-geometry probe
and main's #631 topmost helpers were appended at the same spot. Both kept.

Verified on Windows: rebuilt natives, `check` on decorated-window-tao and
nucleus-application, headful suite 27 run / 0 failed.

Observed geometry was only published from an effect keyed on the v1 state, so
a move or resize the window manager applies without the v1 state changing left
`WindowState.bounds` / `position` / `size` reporting a stale rectangle for the
rest of the window's life. The initial geometry apply is exactly that case: it
lands after the effect has already run.

Bump a counter from the window's own move / resize callbacks and key the
publishing effect on it too. Both binders get it — the Compose-typed one has
the same shape and the same gap.

Caught by the headful suite, which only reproduced it with the full case list:
the filtered run happened to settle in time.

Both conflicts are additive registries where 2.6 and this branch appended at
the same spot: the JVM-only test list (its LCD capture test vs our monitor /
bridge tests) and the headful suite registry (AlwaysOnTopHeadfulCases vs
WindowApiV2HeadfulCases). Both sides kept.

Verified on Windows: rebuilt natives, `check` on both modules, headful suite
32 run / 0 failed, twice.

… API

Written blind on a Windows box and caught by CI. Three mistakes, all verified
this time against the gdk 0.18.2 sources:

- `gtk::gdk::prelude::DisplayExt` does not exist — `Display`'s monitor
  accessors are inherent in gdk3-rs. This is the E0432 that failed the build.
- `Monitor::is_primary()` does exist, so the primary flag no longer has to be
  matched on geometry — which would not have compiled either, since
  `gdk::Rectangle` implements no `PartialEq`.
- `Rectangle` is a boxed inline type, so selecting between the geometry and
  the work area *by value* moved a rectangle still read afterwards. Read the
  four numbers out first and pick between tuples.

Also spell the tab/newline sanitiser as two `replace` calls: the char-array
`Pattern` impl is newer than the toolchain floor this crate builds with.

`gdk::Display::default()` is `assert_initialized_main_thread!()`, and a failed
Rust assertion crossing FFI aborts: the enumeration took the whole test JVM
down with SIGABRT on a headless CI box (exit 134). Guard the no-window path
with `gtk::is_initialized_main_thread()` and report "no monitors" instead, so
a tray-only app or a unit test gets the synthesized fallback rather than a
dead process.

The X11 work-area fallback behind that synthesized monitor is already
headless-safe (`XOpenDisplay(NULL)` returning NULL).

`LcdTextTest > Compose LCD text on an RGB surface has chromatic edges` has
been failing the macOS tao-tests job since #626 merged, which leaves every PR
targeting this branch red.

Skia can only fringe where the platform font host produces subpixel glyph
masks: DirectWrite and FreeType do, CoreText does not — macOS dropped
subpixel antialiasing in Mojave and renders grayscale whatever the surface's
PixelGeometry says. So `lcdScore == grayScore` there, which is this feature's
documented behaviour (`macOS and Linux stay grayscale` asserts the same thing
on the surface-props side) rather than a regression. Skip the pixel assertion
on macOS only; Windows and Linux keep it.

…indow-api-v2

`tao-headful (ubuntu-latest)` timed out on the centring case while the four
other clone cases passed — so positioning works there; it is the *initial*
position that openbox overrides with its own placement policy. The v1 path
retries its Aligned centring for the same reason.

Split the assertion: the size and the strict centre where the platform honours
the request, and containment in the target work area on Linux. Prints the
observed rectangle so the CI log carries the numbers.

The native move / resize callbacks bumped a snapshot-state counter, and those
callbacks run on the event-loop thread from within the platform's resize
handling — which can be *inside* a Compose measure/layout pass. The
recomposition that write schedules then re-entered layout:
`IllegalArgumentException: performMeasureAndLayout called during measure
layout`, which took down the GraalVM headful battery on all three platforms.

Signal through a conflated channel instead. A send carries no snapshot
obligation, and the receiving coroutine resumes on the dispatcher once the
native frame has unwound, so publication happens outside the pass.

`setMenu` reaches `g_bus_get_sync(G_BUS_TYPE_SESSION, …)`, which takes no
timeout: on a runner with no session bus it blocks forever. The test task then
never finishes and hangs the whole `preMerge` job until the 30-minute cap kills
it — the failure mode pre-merge.yaml's own comment records ("`:launcher-linux:test`
has done exactly that three times"), and it just cost another PR two runs.

Skip when neither `DBUS_SESSION_BUS_ADDRESS` nor `$XDG_RUNTIME_DIR/bus` is
there: without a bus there is nothing to register against anyway.

…indow-api-v2

…ow hooks

Rename DecoratedDialog's applyDialogOwnerRelationship to
applyWindowOwnerRelationship and add its inverse,
clearWindowOwnerRelationship, so a second secondary-window archetype can
reuse the Win32 / AppKit / GTK owner plumbing.

TaoWindow gains what a window that observes *another* window needs:
setOuterPositionPx (physical-pixel positioning, SetWindowPos on Windows so
a second-monitor DPI never leaks in), remove*Listener counterparts for the
multi-cast moved / resized / destroyed / fullscreen-prepare hooks, and an
onClosing hook fired at the start of requestClose() so owned windows can
sever their owner link before the OS would take them down with it.

Add SatelliteWindow, the floating tool-palette / inspector archetype on
Tao, with a Nucleus-level overload in nucleus-application:

- WindowPositioner / WindowAnchor / WindowConstraintAdjustment: pure
  placement geometry with a flip → slide → resize cascade, pinned by
  12 unit tests (registered in the scene battery and drift test).
- Anchored initial placement, parent-relative follow in physical pixels
  with echo filtering, offset re-capture when the user drags the
  satellite, suppression while the parent is fullscreen or maximized,
  and SatelliteWindowState.reanchor() to re-apply the rule.
- Reparenting keeps the satellite where it is on screen, including when
  the previous owner closes in the same frame: the owner link is severed
  before the old window is destroyed and the close decision is taken
  from composition, where the new owner is already known.
- Headful coverage: anchoring + follow, maximize suppression + restore,
  reanchor, and reparent-as-the-owner-closes. The harness gains a
  selectable satellite owner, a closable dialog and onCloseRequest
  routing for that last case.
- examples/satellite-demo: two document windows sharing one inspector.

…ble (#576)

The outer gate exists to catch chrome drift — TitleBar and frame disagreeing.
But the outer rectangle is a separate query from the resize event the scene
tracks: on a loaded Xvfb the X server's geometry lagged the scene by 3px over
two consecutive samples while `maxSceneVsInner` stayed at 0, and
`SUSTAINED_FRAMES = 2` promoted that into a failure. Only the outer query can
see such a lag; the scene has nothing to correct.

Fail on outer drift only when the scene also lost the inner size. The metric
line keeps reporting it either way.

Nine of the last nine `preMerge` jobs that hit the 30-minute cap — on main as
much as on feature branches, two of them running the full 6 hours before the
cap existed — were stuck in `:launcher-linux:test`. The culprit is
`g_bus_get_sync(G_BUS_TYPE_SESSION)` with `DBUS_SESSION_BUS_ADDRESS` unset:
GDBus then autolaunches, spawning `dbus-launch --autolaunch`, which waits on an
X display a headless process never provides. No timeout, so the JNI entry
point never returns, and with `nativeRegisterQueryHandler` the calling thread
also sits in a condvar wait for a worker thread that is itself stuck there.

Refuse to connect when the address is unset: a session bus that exists is
always advertised through that variable, so "unset" means "no bus", and the
bridge already treats a NULL connection as "launcher unavailable". This fixes
the headless-app case too — a service or CI process must not spawn dbus-launch.

Guard the second native test the same way (the quicklist one already was), and
drop the `$XDG_RUNTIME_DIR/bus` probe from its check: that fallback is libdbus
behaviour, not GDBus's.

…indow-api-v2

`requestSize` and `WindowBoundsProvider(sizeProvider = …)` pair the size with
`WindowPositionProvider.Current`. Before the window exists that was resolved
against the placeholder rectangle the initial scope hands out, which pinned the
window to an absolute point. The v1 `rememberWindowState(size = …)` idiom this
replaces leaves placement to the window manager — keep that: an initial
size-only request now resolves to `WindowPosition.PlatformDefault`. Once the
window is up, `Current` reads the live outer rectangle as before.

Review follow-up on #634; the other points (AWT on the Tao thread, dummy peer,
dialog constraints, partial min size, host fallback, KDoc) were already
addressed by the clone.

The Linux headful job timed out once on the initial size converging and
passed the run before with the exact requested size; the diagnostic sat
after that wait, so the log had nothing. Print the outer rectangle once a
second during the wait.

Two X11 facts make it say nothing there. openbox applies its own placement
policy to a client's initial position (the window lands at 0,0 — the v1 path
retries Aligned centring for the same reason), so the centre is never
observable. And this is the only headful case whose window receives an
absolute position *before* `show()`: under Xvfb/openbox that window
intermittently stays at GTK's unallocated 1×1 for the whole 15 s budget —
the sizing trace shows it — while the very next window of the same run maps
normally. That is a pre-map race in the v1 create → move → show sequence,
independent of the clone, and not reproducible from a Windows box.

Size, position and screen requests after mapping stay covered on every
platform by the four sibling cases.

Compose's own `androidx.compose.ui.window.v2` types are no longer accepted by
`DecoratedWindow` / `DecoratedDialog` / `HostedWindow` / `HostedDialog` or
the `NucleusWindowHost` / `NucleusDialogHost` surfaces. On Tao that surface
could only ever be half-working — every scoped geometry provider (including
the ones `requestSize` / `requestPosition` build internally) and `requestScreen`
were accepted, logged and dropped, because Compose's scope needs a displayable
`java.awt.Window`. An API that silently ignores part of its contract is worse
than one that does not exist; the supported v2 surface is the clone,
`dev.nucleusframework.window.tao.v2`, where everything is applied and
migrating is one import.

Removed: `ComposeWindowV2Bridge`, the `ComposeWindowV2Access` friend-package
accessor, the Compose-typed `DecoratedWindow` / `DecoratedDialog` overloads,
`inspectableWindowBounds` / `requestInspectableBounds`,
`rememberSyncedWindowState` / `rememberSyncedDialogState`, the matching
nucleus-application overloads, adapters and host methods, and their tests.
The geometry helpers the clone shared with that bridge move into
`NucleusWindowV2Bridge`. `examples/tao-demo` and the host tests use the clone.

PKG was hardwired to the Mac App Store: TargetFormat.isStoreFormat forced
the sandboxed pipeline, "3rd Party Mac Developer" certificates and a
post-build productsign, so a PKG for MDM deployment or manual install
outside the store was not buildable.

Whether a PKG is a store package is now a DSL choice, macOS { pkg {
appStore } }, defaulting to the previous behaviour. With appStore = false
the PKG takes the same non-sandboxed pipeline as the DMG, electron-builder
signs the installer itself from the bare NAME (TEAMID) identity, a DSL
keychain travels as CSC_KEYCHAIN, and notarizePkg notarizes the .pkg.
electron-builder silently emits an unsigned package when no matching
"Developer ID Installer" certificate is found, so the task verifies the
result with pkgutil --check-signature.

pkg { preInstall / postInstall } stage install scripts for pkgbuild
--scripts. The App Store rejects them (error 90254), so they require
appStore = false, checked at configuration time.

The staged preinstall/postinstall are shims. electron-builder sets
BundlePre/PostInstallScriptPath *and* passes --scripts, so PackageInfo
declares each script twice and the Installer runs it twice, confirmed on
a real install. The shim skips the per-bundle pass and execs the app's
script, staged under a name electron-builder's scan does not match.

Runtime: ExecutableRuntime.isSandboxed() reads APP_SANDBOX_CONTAINER_ID.
The scheduler gates on it instead of isPkg(), and a Developer ID PKG
becomes self-updatable while the sandboxed store build stays excluded.

The ignored-projects list was maintained by hand, so every new sample had
to be added to it. Twice it was not, and apiCheck failed with "Expected
file with API declarations ... does not exist" for macos-appex-demo and
reader-dock-demo.

Excluding every :examples: subproject removes the class of failure. The
predicate matches the one already used for detekt and explicitApi() lower
in the file. decorated-window-jewel stays listed explicitly: it is not a
sample, it is BCV's ASM being unable to read JVM 25 class files.

feat(pkg): Developer ID PKG with install scripts (#249)

ktlintCheck was failing on nucleus-2.6 independently of any branch:
chain-method-continuation on the two kover plugin applications in the root
build script, and an unused NucleusDecoratedWindowScope import in
satellite-demo. Applied ktlintFormat to those two targets only, so the
change is limited to them. detekt, ktlint and apiCheck are now green
across the whole build.

… UI thread

`NotificationCenter` dispatches its delegate callbacks on a worker pool of
its own ("NucleusNotificationCallback-N"), so the portable `notification { }`
callbacks were the only ones left off the host UI thread on macOS while the
Linux and Windows bridges already post to it.

Verified on macOS with a real notification: clicking a button, the body and
the close box now all reach Kotlin on the Tao main thread (the thread Compose
composes on), instead of `NucleusNotificationCallback-1`.

`onFailed` from the `add()` completion takes the same route, since that
completion comes off the same pool.

#444)

On Wayland `wl_egl_window_resize` only records a *pending* size: the buffer
behind the default framebuffer is reallocated inside the next
`eglSwapBuffers`. Skia's render target wraps that framebuffer (`fbId = 0`),
so building it from the size we just requested overstates it for one frame,
and under `SurfaceOrigin.BOTTOM_LEFT` the frame lands that many rows off the
top of the real drawable — the band of clear colour the issue sees flicker
on roughly a third of the frames of a drag.

Both earlier attempts predicted that size rather than reading it: first "the
buffer follows the request" (the flash), then "the buffer is one present
behind", which had to be confined to KWin because the prediction was wrong
elsewhere — it fixed Fedora Mutter and regressed Ubuntu GNOME.
`eglQuerySurface` is neither prediction but the answer, so there is no
desktop environment left in the decision: `useDrawableSizedPaint`,
`drawableWidthPx` / `drawableHeightPx` and `onDrawablePresented` are gone.
Where a driver answered with the requested size instead of the real one, this
would behave exactly as the code did before it.

Layout and the render target are also separated, which is what made the
earlier attempt a trade-off in the first place: the scene keeps the window's
size, so Compose never measures for a buffer that is a step behind, and only
the render target follows the drawable. A frame drawn while the buffer lags
is then anchored correctly and merely leaves that step uncovered until the
catch-up frame, instead of displacing everything by it.

Measured by a new headful case against a nested compositor: 16 of 64 frames
painted at a size the buffer did not have before, 0 after, the window
converging to its final size. The case fails when it measured nothing — it
requires the window to have actually changed size, and reports the render
passes dropped on a swap still in flight, because a window the compositor
treats as occluded never gets its frame callbacks, renders nothing at all,
and used to look exactly like a pass. `taoHeadfulTest` now forwards
WAYLAND_DISPLAY so the suite can be pointed at a nested compositor instead
of whichever session owns the screen.

Defects (1) and (3) of the issue are untouched: the buffer still does not
arrive in the same commit as the window geometry, which is a commit-ordering
problem between GTK's toplevel and our sub-surface rather than a render
target one.

fix: marshal native callbacks to the host UI thread, not the AWT EDT

Querying the drawable instead of predicting it is only authoritative if the
driver cannot act on the pending `wl_egl_window_resize` after the answer is
given. That held on Mesa, which defers the reallocation to `eglSwapBuffers`
(measured: 0 of ~180 frames changed size under the frame). It does not hold on
the NVIDIA proprietary driver, which reallocates when the back buffer is first
used for rendering — in the middle of our frame, after the render target was
built (measured on Ubuntu 26.04 / RTX 5060 Ti / 595.84: 12 of ~80 frames).

So pin the moment rather than predict it per driver: on the frames that pushed
a resize, bind the default framebuffer and clear it before querying, which is
the first use either driver is waiting for. The answer then describes the
buffer the whole frame lands in on both. The clear is not extra work — the
frame clears anyway — and it is confined to resize frames because it costs a
Skia GL state reset.

The render target is built from one `eglQuerySurface` taken before the frame,
which is only authoritative if the driver cannot act on the pending resize
afterwards. Drivers differ on exactly that, so the case reports the frames where
it happened anyway and prints what the buffer became, which is what tells a
stale basis from a correct one.

This is what identified the NVIDIA behaviour: 12 of ~80 frames per run there,
0 of ~180 on Mesa, every one of them `queried -> requested` — Skia painting at
the pre-configure size into a buffer that had already reached the new one.

Both said more than what was measured, which is the same mistake that produced
the desktop-environment branch this change removes.

- The paint-size KDoc claimed the queried drawable never changes under a frame,
  measured on Mesa and stated flatly. It changes on the NVIDIA proprietary
  driver; say which driver does what, and point at the call that pins it.
- The headful case claimed compositors ignore `setInnerSize` "(this one does)".
  Mutter 50.1 honours it — #576 drives 40 distinct sizes through it. The case
  still drives maximize/restore, but because a client resize is advisory and a
  session that drops it would leave the case measuring nothing, not because
  compositors reject it.

…e-sized-paint

fix(tao/linux): paint at the drawable's real size, not a predicted one (#444)

The badge a Caps Lock bound to keyboard-layout switching raises is a window
HIToolbox creates *inside our own process*, positioned from whatever
`firstRectForCharacterRange:` answers. TaoView answered a process-global caret
rect that nothing ever invalidated, so once a focused text field was destroyed
the badge kept appearing over the spot the field used to occupy. Before any
field had been focused it was worse: the overrides were only installed when the
first text-input session started, so tao's own implementation answered — the
content-rect corner with a *top-down* y handed back as a Cocoa bottom-up
coordinate — which parks the badge in the bottom-left corner of the screen of
an app that has never shown a text field.

Three changes, all measured against a logging `NSTextInputClient` probe driven
by `TISSelectInputSource` with the badge window tracked through
`CGWindowListCopyWindowInfo`:

The cached rect is now scoped to the view that pushed it, and every other
answer is `NSZeroRect`. That exact shape is the one AppKit reads as "no
insertion point": a zero *size* alone does not suppress the badge — `(0, 30,
0x0)`, which is what tao answers, still draws it — and `selectedRange =
NSNotFound` plus `invalidateCharacterCoordinates` change nothing at all. A
rect falling outside the key window is not drawn either, which is why the
corner case only shows on a window large enough to contain it.

The overrides are installed per window creation rather than on the first
session, so the answer is ours from the first frame. `TaoView` only exists once
a window has been built, and the swizzle is idempotent.

The input context is deactivated when the session ends. On its own that is not
enough — `interpretKeyEvents:` re-activates it on the next keystroke — but it
takes the badge down immediately for an app that is not being typed into. The
teardown carries the activation token it was handed, because focus moving
between fields starts the incoming session *before* the outgoing one is torn
down: without the guard, focusing a second field deactivates the context the
first teardown then finds live. Same ordering trap as the document cache.

`MacOsTextInputClientProbe.imeRect` reads what TaoView answers AppKit and
reports an all-zero rect as "no insertion point", which is the property both
cases assert.

`caretRectDiesWithTheFocusedField` walks one field lifecycle: the caret is
published, it follows focus to a second field (the ordering guard — without it
the run takes three times as long because the incoming session's context is
deactivated and has to be re-established), it is dropped when the fields are
destroyed, a keystroke does not republish it, and a field composed again gets
it back. `noCaretRectBeforeAnyField` covers the window that never shows one.

Both fail on the code before this branch.

…indicator

fix(tao/macos): keep the input-source indicator off a caret that is gone

AppKit fires `mouseExited:` for a cursor that never left the view. Measured on
26.5 with the pointer parked over a tab strip: enter → exit → enter → exit, all
at one screen point. Two sources found — a hover card's own popup panel rising
over the pointer, which is a *child window* of ours whose draw margin overlaps
the tab it hangs off, and the rebuilds of tao's legacy tracking rect.

That reaches Compose as `PointerEventType.Exit` and is taken at face value, so
hover state is dropped. Nothing corrects it: `CursorEntered` carries no
position and was never forwarded, and a pointer that *rests* sends nothing
more. Hover effects and tab hover cards stay dead until the user moves the
mouse — the symptom the standing HACK comment in `TaoComposeSceneHost`
describes as "hover doesn't render until the user clicks once". A hover card is
worse than dead: it dies on its own phantom exit, reopens, and exits again, a
loop no pointer can break.

So trust the geometry over the event. An exit is ignored when the cursor is
demonstrably still ours — inside the view's bounds, and the window on top at
that screen point is this window or one of its `childWindows` — and the
position is re-published instead; `CursorLeft` is kept for a cursor that really
is somewhere else. `mouseEntered:` publishes its position for the same reason.

`a popup outside the owner window is left alone while the screen has room`
needs the popup to land outside the window *and* inside the work area at once.
The default 800 dp window centred on the runner's 1024 px display leaves 112 px
for it, so the popup was clamped back in — on the case whose whole point is
that nothing clamps. A small window against the left edge has room anywhere we
run.

The two cases that need a window *above* the work area are asking for a state
macOS does not have. Measured on 26.5: `setFrameOrigin:` and `setFrame:display:`
both pull a frame whose top would go under the menu bar back down, titled and
borderless alike, and only an override of `constrainFrameRect:toScreen:`
escapes — not a trade Nucleus makes, since AppKit runs that constraint on
display changes too and a window it no longer keeps on screen is a window the
user cannot reach. A user cannot drag a window off the top there either. They
skip on macOS with that reason and stay covered on Windows and Linux, where the
drag is an everyday gesture.

`Robot.mouseMove` warps the cursor on macOS, and the events that follow a warp
carry the *pre-warp* location for a few hundred ms — measured as ten
consecutive moves all reporting one stale point. A press sent inside that
window is hit-tested where the pointer used to be, so a case that clicks
straight after moving clicks the wrong thing.

`robotPressAndDrag` now lands on its start point in two hops, the second a real
move from the cursor's new home, which is what flushes the true location
through. Same shape as the pattern `NativePopupMarginInputHeadfulCases` already
used for its pointer cases.

…r it (#444)

Two ordering defects made the content trail the window by one configure
on every commit of a Wayland resize — visible as the jump on a left/top
edge drag, where the origin moves a step ahead of the content.

1. Tao's GTK `draw` and `configure-event` handlers only post to its event
   channel: `RedrawRequested` / `Resized` reach the host after GDK's
   after-paint has already committed the toplevel with the new
   `set_window_geometry`. The frame for configure N could never ride
   commit N. The widget helper now connects a real `draw` handler on the
   GtkWindow (`nativeConnectToplevelDraw`); during a resize burst the host
   renders from it, taking the size from `gtk_window_get_size` (GTK's own
   configure-event lags the same way), with the content sub-surface in
   `set_sync` and the swap at interval 0, and waits for the swap before
   returning — so the buffer is cached compositor-side when GTK's commit
   applies it, atomically with the geometry. Sync is armed only from an
   idle swap thread and only with the interval-0 burst, or a commit with a
   frame callback attached would wait for the very GTK commit the draw
   has yet to return to. The swap interval is now applied by the swap
   thread before its present, so it is in force before the first synced
   commit.

2. Mesa's `wl_egl_window` resize callback adopts the new size only while
   no back buffer is acquired, and `eglMakeCurrent` acquires one: a
   resize pushed after it lands in the next frame's buffer, and this
   frame paints the previous size. `applyPendingNativeResize` now runs
   before `nativeMakeCurrent`; the Skia surface rebuild a scale change
   asks for is deferred to when the context is current.

Measured with a compositor-driven left-edge resize (KWin scripting,
30 steps of 8 px) and screen capture, counting frames where the
content's right edge moves — which it never does for a plain GTK3
window: before 64–82 of ~300 frames, after 0 on three runs. A
WAYLAND_DEBUG trace pairs every GTK geometry commit with a child buffer
of exactly that width (100/100).

…arded

A native popup layer hands its parent every mouse event that lands in the
margin it draws its shadow in. AppKit, though, keeps a whole button gesture on
the window that took its mouseDown — this panel — so the parent was being given
a press whose end it could never see. Two ways to lose it, both measured on a
tab strip's hover card: the region hit-test answers differently on the way up
(the press is what dismisses the card, which re-lays out the content under the
pointer), or the panel is ordered out between the two, and an ordered-out
window receives nothing at all. The release then reaches no one: not the panel,
not the owner's view, not the JVM.

What the owner is left with is a press that never ends. Compose holds the
gesture open, so the click it belonged to never happens — the tab under the
pointer is not selected — and the next press is read against the stale state
(`TaoComposeSceneHost` closes it out there, which is why a second click
appeared to work).

So the panel now tracks which buttons it forwarded: the rest of that gesture
follows its press to the parent whatever the region test says, and a panel
ordered out still holding one hands over the release AppKit will not deliver.

The two appearance comparisons failed intermittently on a real display, on
metrics that read one frame each.

`firstVisible` — and `slideIn`, measured from it — anchored on the first frame
where the colour probe caught the dialog. The dialog fades in over the scrim,
so that frame sits on the knife-edge of the detection threshold: it came out
bimodal on *both* layers, 0 ms on the runs that caught the faint start and
~60 ms on the runs that did not, and the comparison failed whenever the two
films happened to land in different modes. They now anchor half-way through
the fade, far from that edge and the same moment of the same animation either
way.

`hideMinHeightRatio` took the strict minimum over the fade-out. What it guards
against is a surface that *stays* collapsed for the whole fade; a single short
frame is a drawable caught mid-present, which an OS surface can show and a
scene drawing into the window canvas never can (measured: 1 px, and half the
dialog, in runs whose neighbouring frames were both full height). Read over
two consecutive frames it keeps the guard and drops the compositor.

…frame-ordering

fix(tao/linux): commit the resize frame with GTK's geometry, not after it (#444)

…mized

A maximized, tiled or fullscreen window has no CSD shadow ring, so the
content sub-surface's opaque region covers the toplevel edge to edge.
Mutter culls such a parent as obscured and stops answering its
`wl_surface.frame`; GDK freezes its frame clock on the unanswered
callback of the last commit GTK made in that state.

Two symptoms followed the #444 in-frame path:

1. The whole UI froze on maximize. The burst rendered only from GTK's
   `draw`, and its end was only evaluated inside the render pass — with
   GTK unable to paint, no frame was ever rendered again, and the
   coroutine continuations drained there never resumed. The burst's end
   (`endResizeBurstIfStale`) now runs from `onRedrawRequested` too, every
   `queue_draw` is watched (`askToplevelDraw`, 50 ms grace + a watchdog
   redraw through `DelayScheduler`) and an unanswered one drops the burst
   back to the event-loop path; the in-frame path is never armed while the
   window is maximized / tiled / fullscreen (`parentObscured()`).

2. Hover and drags were choppy while maximized although the app rendered
   at full rate. GDK3 holds a lone motion event until the frame clock's
   flush-events phase, which does not run while the clock is frozen, so
   motion was only delivered when another event arrived. GTK repaints
   the toplevel once after every maximize (`applyContentOffset`, to land
   the sub-surface at (0, 0)), and that commit went unanswered. The
   content's opaque region now always leaves its bottom row out, so the
   compositor keeps painting the toplevel and its callbacks keep coming.

Measured with WAYLAND_DEBUG over 9 maximize/restore toggles: every one of
the parent's 67 frame callbacks answered, max latency 25 ms (before: 2.5 s
or never), content at 90 fps throughout, no protocol gap over 22 ms.

A tag `v<semver>-dev-<id>` (convention `v2.6.0-dev-YYYYMMDDHHMM`, cut by the
`tag-dev` skill) now publishes the runtime modules to Maven Central and the
plugin to the Gradle Plugin Portal without running `preMerge` — the usual
Kotlin-ecosystem dev build, so a downstream app can consume 2.6 before it is
released. Natives are still built and verified; the JARs would be unusable
otherwise. Nothing else in the publish graph runs tests: `publishToMavenLocal`
pulls in `compileKotlin` → `jar`/`sourcesJar`/`javadoc` → `pom`/`publish` and
neither `test`, `apiCheck` nor `detekt`.

`release-tag-info` is the single place that classifies a tag. It also rejects
anything that is not `v<semver>`: every module derives its version with
`GITHUB_REF.removePrefix("refs/tags/v")`, so a bare `dev-2026…` tag would have
published a version literally named `refs/tags/dev-2026…` — permanently, on
Central.

Dev tags are excluded from `release-desktop` / `release-graalvm`: they publish
libraries, they should cut no GitHub release and burn no packaging matrix.

`validate-release-ref` now derives the branch a prerelease tag must live on from
the tag itself (`v2.6.0-rc.1` → `nucleus-2.6`). The pinned default was still
`nucleus-2.0`, a branch that no longer exists on origin, so the next rc would
have failed to fetch — the guard was protecting the previous release line.

The edge double-click zoom (`-[NSWindow _zoomToScreenEdge:]`), the
Window-menu tiling and `zoom:` all end in AppKit's
`setFrame:display:animate:YES` — a blocking animator whose private
run-loop mode services no tao observer, so every step's `Resized` sat in
tao's queue until the animation had ended and the content snapped into
the final bounds: the #576 trailing, one path over.

`TaoWindow` now overrides `setFrame:display:animate:` and routes every
animated frame change to `util::animate_frame`, the stepper #678 wrote
for `set_maximized_async`, which now simply calls
`setFrame:display:YES animate:YES` (the resizable and non-resizable
branches merge). Guarded by `in_fullscreen_transition` / `fullscreen`
so the AppKit fullscreen transition (#327) is untouched.
`window_delegate::shared_state_of` reaches the `SharedState` from the
window class.

Headful gate `#576 AppKit frame animation (edge double-click zoom)
dispatches every step in time` drives the same AppKit path
programmatically (`setResizable(false)` + maximize) and asserts that
every `Resized` is dispatched while the native frame is at its size:
42 events up to 1880 px off before, 41 events at 0 px after.

…-576

fix(tao/macos): step AppKit's own frame animations too — edge double-click zoom (#576)