runtime(track-a): validate causal worldmap server delivery

[blakinio]

Objective

Execute the separately owner-authorized physical causal discriminator from merged #473/#474: compare authoritative server-delivered worldmap data for the exact baseline [18,14] versus the first conservative task-owned [19,14] mutation.

Owner authorization was given in the current conversation after the prior hard stop explicitly stated that physical runtime plus client-byte mutation required separate authorization. This PR records that authority but does not bypass Track A admission/lease/Gate A/bootstrap/rebind/Gate B.

Initial admission is fail-closed canonical_bootstrap discovery only. No process/X11/client observation or launch is legal until fresh controller-plane inventory is persisted and the task admission is updated.

Required causal result:

SERVER_MAP_DELIVERY_MODEL=CLIENT_DRIVEN|SERVER_DRIVEN|NEGOTIATED|FIXED_PROTOCOL|UNKNOWN
PATCH_CAUSES_ADDITIONAL_AUTHORITATIVE_MAP_DATA=true|false|UNKNOWN
BASELINE_AUTHORITATIVE_INBOUND_EXTENT=<measured or UNKNOWN>
PATCHED_AUTHORITATIVE_INBOUND_EXTENT=<measured or UNKNOWN>
OUTBOUND_EXTENT_NEGOTIATION_CHANGE=true|false|UNKNOWN
STORAGE_EXTENT_CHANGE=true|false|UNKNOWN
RENDER_PICKER_EXTENT_CHANGE=true|false|UNKNOWN

Safety: serialized Synology Track A runtime only, at most one logged-in session at a time, WARP/SOCKS confinement, no source patch in place, no credential output/artifacts, no owner-funded Codex/OpenAI API, exact rollback required, one exact canonical bootstrap budget and one patched ephemeral login budget.

[blakinio]

Coordination note after run 32031119012 / 95391127666: the normalized 1020x650 arm again stopped pre-secret with WORLDMAP_XRES_UI_WINDOW_ERROR=...no viewable 1020x650 candidate, while the same run had already emitted WORLDMAP_BASELINE_WINDOW_IDENTITY=x11-window:12582929, WORLDMAP_BASELINE_TARGET_UNIQUENESS=PROVEN, and WORLDMAP_BASELINE_PRE_STORAGE_OBSERVER=ARMED; source rehash/cleanup PASS and no WORLDMAP_BASELINE_LOGIN_SUBMITTED=true. This makes another enumerative retry inappropriate. Suggested changed-hypothesis discriminator: directly revalidate the already-proven manifest WIN at point-of-use (XGetWindowAttributes: viewable + 1020x650, and XRes LocalClientPid(WIN)==PID) and use it as UI_WIN only if that current-XID revalidation passes, rather than re-enumerating the whole X11 tree. This remains pre-secret and preserves fail-closed identity semantics.

[blakinio]

Runtime evidence update from canonical KasmVNC session (otclient-track-a-kasmvnc, DISPLAY :1) on current official client 15.32.bf29ac, SHA-256 ed5469b9fa71349de688f719434d23875f76f28a3ebd08a36d30f7f6da0af6b8.

FACTS:

• Active in-game client window owned by PID 995; initial TracerPid=0.
• Current-build QMeta rediscovery: tibia::worldmap::TWorldmapProtocolMessageHandler static metaobject 0x30ba6c0, static_metacall=0xe030c0, 14 methods.
• Direct current-build handlers recovered and physically hit: FullMap=0xceea80, row/column family around 0xceecc0..0xceee10.
• Current-build map-description parser anchored at 0x1991640; strip-coordinate observation point 0x1991af8.
• Privileged one-shot GDB attach/detach smoke PASS; client remained alive.
• Physical movement W hit direct TopRow handler.
• Physical movement S hit BottomRow; parser yielded current-floor (z=7) unique X coordinates 32540..32557 inclusive => 18 columns.
• Physical movement A yielded current-floor unique Y coordinates 32494..32507 inclusive => 14 rows for the newly delivered column.
• Physical movement D returned east and yielded the corresponding right-column strip on x=32557, again spanning current-floor Y 32494..32507 => 14 rows.
• Adjacent-floor (z=6) data also appeared in the same movement-driven parse stream.
• Debugger detached after capture; TracerPid=0; client alive.

Conclusion (FACT): for this live current-client session, authoritative movement-driven map delivery on the current floor is empirically consistent with a server-delivered extent of 18 x 14. This upgrades the former static 18/14 finding to live server-delivery evidence on current SHA.

Still UNKNOWN: whether client mutation to [19,14] causes the server to deliver >18x14 authoritative map data. Next causal step remains patched-current-build comparison, but baseline 18x14 is now physically established without consuming credentials/login automation.