Gate the Android accessibility publish on assistive-tech state and batch it at Compose parity

[samoylenkodmitry]

This is a correctness and battery fix. It does not improve frame rate.

The stage numbers below are real and reproduce. They do not convert into
fps, and the PR should not be merged expecting a faster scroll. A
same-package, same-data, same-thermal-state A/B on cranscan:

arm	fps	sync p50
baseline rep 1	41.60	5.12 ms
baseline rep 2	40.34	5.16 ms
patched	40.55	0.00 ms

That is one noise band. Stage sums say why: ~22.4 ms → ~19.4 ms against a
~16.1 ms vsync budget. The frame misses the same vsync either way — you do
not get paid until you cross 16 ms. Confirmed a second way by flipping
debug.cranpose.a11y_sync inside one binary: 41.47 fps off vs 41.51 fps on.

Publishing an accessibility tree every frame while nothing is listening is
pure waste and worth removing on its own terms. The actual scroll work is
#500, whose ranked causes (35 render passes, 9 isolated layers, 34.6 %
layer-cache hits) were re-verified on a quiet device and are the critical
path.

Problem

Scroll on a 2018 Huawei (EVR-AL00, Kirin 980, 60 Hz) is laggy in cranpose apps. On-device per-stage frame telemetry (debug.cranpose.frame_telemetry) showed the sync stage — the Android accessibility bridge — costing 6.3–6.7 ms of every 16.7 ms frame while scrolling, the single largest CPU stage of the loop (frame CPU p50 ≈ 12.7 ms, zero headroom).

Every frame whose semantics revision moved (= every scrolled frame) did a full layout+semantics tree walk, a full TSV encode, a JNI hop, and a Java-side parse on the frame thread — whether or not any assistive technology was running.

Confirmed by removal: a probe build skipping the sync dropped frame CPU p50 from 12.7 ms to 5.5–9.7 ms.

Fix

• New accessibility_publish_policy.rs — pure, host-tested policy (9 unit tests): publish nothing while no assistive technology is active; while one is, publish at most once per 100 ms — Jetpack Compose's SendRecurringAccessibilityEventsIntervalMillis.
• CranposeActivity mirrors AccessibilityManager state into native (nativeOnAccessibilityStateChanged, registered in onCreate, removed in onDestroy); enable transitions force a full republish.
• A publish deferred by the throttle window arms a poll-timeout wake, so the trailing tree state lands even when the loop goes idle.
• The Java payload parse moved off the frame thread into the posted UI-thread task.
• A/B knob: debug.cranpose.a11y_sync / CRANPOSE_A11Y_SYNC (0 force off, 1 force on).

Measured on device (demo lazy list, EVR-AL00)

metric	before	after (a11y service active)
sync stage mean	6.4 ms/frame	0.3 ms/frame
sync per publish	6.5 ms every frame	~2.4 ms, 10×/s
frame CPU p50	12.7 ms	~9 ms (5.5 ms bridge off)

uiautomator dump (reads through the real AccessibilityNodeInfo path) still returns the complete virtual tree at the scrolled position, so screen readers keep working with Compose-equivalent freshness. This device runs a phone-control accessibility service permanently, so the throttled path (not just the off path) is what fixed it here.

Gates

just fmt / typos / versions / test / clippy / doc / just android all green. just budgets fails on the macOS dev host only (pre-existing objc2* duplicate families; the CI gate runs on Linux where those crates never resolve — no manifests or lockfile touched here). Robot suite untouched: all changed code is Android-target-gated or test-only.

Also included: TIME_WASTERS.md entry on Android on-device scroll-perf measurement traps, and a .gitignore for the gradle-plugin's local build dirs.

🤖 Generated with Claude Code

[samoylenkodmitry]

Device trace: this is the top cost in a real app, not a micro-optimisation

Traced cranscan (real app, 15-document library with thumbnails) on the Huawei EVR-AL00, thermals cool and verified unthrottled (GPU 37 °C, CPU 41-42 °C, mStatus=0). Per-stage medians during a long-drag scroll:

stage	Library (glass cards)	Settings (no glass)
update	4.59 ms	4.74 ms
sync (this PR)	5.55 ms	7.10 ms
acquire	0.58 ms	0.58 ms
render (CPU encode)	8.17 ms	5.96 ms
present	15.39 ms	9.44 ms
CPU excl. present	18.89 ms	18.38 ms
frame period	34.96 ms (~28 fps)	28.14 ms (~35 fps)

Two things fall out:

The GPU is not the bottleneck. acquire is 0.58 ms on both pages. If the GPU were behind, get_current_texture would block waiting for a free swapchain image; it doesn't, so the swapchain always has one ready. The long present is the pacing wait behind a CPU frame that already blew its 16 ms budget.

The cost is not the glass, either. A page with six-to-eight isolated glass layers and one with none have nearly identical CPU per frame (18.89 vs 18.38 ms). Whatever is eating the budget is paid on every screen.

sync — the per-frame accessibility publish this PR gates — is 5.5-7.1 ms of that, i.e. 29-39 % of the frame's CPU, and it is pure overhead: no assistive technology is consuming most of it, and what is consuming it does not need it at 60 Hz.

Subtracting just this stage puts both pages under one vsync (13.3 ms and 11.3 ms against a 16 ms budget), which is the difference between quantising to two vsyncs and hitting the panel rate. The mechanism is already A/B-proven on the demo in this PR's own numbers: cpu p50 12.5 → 5.5 ms with the bridge gated.

I have not yet built cranscan against this branch, so I am not claiming the fps number — only that the stage this PR removes is the single largest addressable item in that frame, measured. That build is the obvious next verification.

Worth noting for prioritisation: this reorders the work in #500. I had assumed cranscan's 15-17 fps was GPU-bound on backdrop blur; the trace says the render-pass and backdrop-cache work there, while real, is second to this.