No support for Intuition system Requesters (struct Requester) — CLICK/TREE can't see or act on them

[sidick]

Problem

Confirmed via a full source grep (Requester/IDCMP_REQ/AutoRequest/
EasyRequest/SysReq — zero matches anywhere in server/,
intuition-model/, amiinspect/, host/, manifest/, docs/,
userdocs/): AmiPilot has no support at all for Intuition's
Requester mechanism (struct Requester, intuition/intuition.h) —
the modal boxes behind Request()/AutoRequest()/EasyRequest(),
covering both an application's own "Are you sure?" dialogs and
system-wide ones (disk-swap "Please insert volume X", DOS error
requesters, Software Failure/Guru).

This is architecturally distinct from every locator this project
already supports: a Requester's content (its OK/Cancel-style buttons,
its body text) lives in its own ReqGadget list, reached via
window->FirstRequest (window-attached form) — not
window->FirstGadget, which is the only chain
intuition-model/src/walk.c's WalkGadgetList() ever iterates. So
even a window that TREE already finds successfully will show nothing
useful once a Requester opens over it, and CLICK/GETTEXT have no
locator that can reach a Requester's gadgets by any means (GA_ID,
ROLE=, or otherwise) since the walker never sees them.

AutoRequest()'s own autodoc (BuildSysRequest(), which it's built
on) confirms a system-wide requester (no owning window — the
common case for disk-swap/DOS-error/Guru requesters) can come back as
a genuine struct Window of its own, separate from any application
window. That window would currently be findable by AmipFindWindow()
(it walks every screen's window list) — but its actual box/text/gadgets
are still only reachable through that window's FirstRequest chain,
same gap.

Practical impact

• A test driving real, unmodified software (the stock-app-conformance
  goal this project already holds itself to) has no way to detect or
  dismiss an unexpected requester — a disk-swap prompt, a "file
  already exists, overwrite?" dialog, a crash/Guru — via CLICK. The
  automation session likely just stalls waiting on a WAITFOR/TREE
  that never sees what's actually blocking the target window.
• Reported by @sidick during hardware-adjacent testing setup (a real
  Picasso96 3.6 install on the amipilot hard drive, uaegfx enabled)
  as a real gap worth tracking, with manual click-through as the
  interim workaround.

Proposed design (sketch, not yet scoped in detail)

• Discovery: extend intuition-model's walk to also report a
  window's FirstRequest chain (or the presence of one) — a
  Requester's own LeftEdge/TopEdge/Width/Height/ReqGadget
  list is real, walkable structure, the same shape as a window's own
  gadget list, just reached differently. TREE's output would need a
  way to represent "this window currently has an active requester"
  distinctly from its normal gadget tree.
• System-wide requesters: since BuildSysRequest() can produce a
  standalone window with no application owner, AmipFindWindow()
  already reaching it is necessary but not sufficient — its content
  still needs the same FirstRequest walk as the window-attached
  case.
• Action: CLICK's existing ROLE=/INDEX=/GA_ID locators
  would need a way to target a Requester gadget specifically (a new
  locator prefix, e.g. REQ=?), since GA_ID on a Requester's
  ReqGadget list could collide with the owning window's own
  FirstGadget IDs.
• Detection without acting: a WAITFOR-style condition
  ("a requester appeared on window X") would let a test at least
  assert on / react to an unexpected requester rather than only
  silently timing out, even before full requester-gadget targeting
  lands.

Why now

Filed per @sidick's request while setting up real hardware-adjacent
testing (Picasso96 3.6 + uaegfx installed on the amipilot test hard
drive) — noted as a real, currently-unaddressed gap to track rather
than something to silently work around; manual click-through remains
the interim path until this is designed and scoped properly.

[sidick]

Detection-only slice landed in #70: WAITFOR [SCREEN=<s>] REQUESTER [TIMEOUT=<n>] polls server-side until a genuine Intuition Requester appears, so a test can now assert "a requester appeared" instead of silently stalling. Matching host client support: wait_for("requester").

Scope: window-attached Requesters only (the common in-app case: Request()/AutoRequest()/EasyRequestArgs() called with a real owning window). A system-wide Requester with no owning window (a disk-swap prompt, a DOS error, Guru/Software Failure) is still undetected — BuildSysRequest()'s own autodoc says these can come back as a standalone struct Window, but reliably telling that apart from an ordinary app window needs more research than this pass covered. That, and full interaction (clicking a Requester's own gadgets — a separate ReqGadget chain from window->FirstGadget, needing its own locator scheme to avoid GA_ID collisions with the owning window), remain open under this issue.

Worth flagging: the detection mechanism ended up different from what the RKRM/NDK autodocs describe. Confirmed live against a real AutoRequest() call (fixtures/gadtools-app's new Ask button): on this project's target OS/ROM, AutoRequest()/BuildSysRequest()/EasyRequest() given a real owning window do not populate window->FirstRequest (the classic Request()-based struct Requester chain), and the Positive/Negative gadgets do not carry the GTYP_REQGADGET bit BuildSysRequest()'s own autodoc documents on them either. Instead, per that same autodoc's own text ("a new window is opened in the same screen as the one containing your window"), it's a genuinely separate struct Window — one that happens to share its owner's exact title text, which no ordinary well-behaved app window does on its own. Detection uses that title collision as the real signal (FirstRequest is still checked first, both because it's free and in case a future genuine Request()-based interaction path relies on it directly). Full writeup in WaitForRequesterPresent()'s own comment, server/src/amipilotserver/main.c.

[sidick]

Investigated the design sketch above before implementing it, and the premise turned out to be wrong for this project's real target OS/ROM — good news, not a setback.

A window-owned AutoRequest()/BuildSysRequest()/EasyRequest() requester doesn't attach invisibly to the owning window's FirstRequest/ReqGadget chain at all. It opens as a completely ordinary, separate struct Window sharing its owner's exact title text (confirmed live via TREE: while the requester is up, the same window pattern resolves to a different window with a real, directly-walkable gadget list). That means ordinary CLICK <window-pattern> <gadget-id> already reaches it today — no REQ= locator, no wire protocol change, no TREE representation work needed. BuildSysRequest()'s own autodoc documents a fixed, app-independent GadgetID convention (TRUE=1 positive, FALSE=0 negative), confirmed live by actually clicking it and watching a real AutoRequest() dismiss — see PR #82.

Narrowing this issue's remaining scope to what's genuinely still open:

• Body text isn't readable. A requester's ReqText is rendered directly as IntuiText, never exposed as a gadget attribute — GETTEXT has nothing to target.
• System-wide requesters (no owning window) are still detection-only. BuildSysRequest(NULL, ...) — the real disk-swap/DOS-error/Guru case — opens on the default public screen with no known title to pattern-match against at all. This is the genuinely harder half or the RKRM-sketch case that motivated filing this issue; still unaddressed.

Leaving open for those two.

[sidick]

Follow-up on the body-text question flagged in my previous comment: settled it, live, as a confirmed permanent limit, not open work.

struct Requester->ReqText (a struct IntuiText *, per BuildSysRequest()'s own autodoc) would be the obvious field to read a requester's body text ("Are you sure?") back from — but a temporary diagnostic (dumping FirstRequest/ReqCount for every open window while a real AutoRequest() was up) showed both NULL/0 on both the owning window (genuinely blocked inside AutoRequest() at the time) and the requester's own separate window (the one PR #82 confirmed CLICK can already dismiss). No struct Requester exists anywhere reachable in this scenario on this project's real target OS/ROM — the body text is rendered directly into the requester window's own bitmap at open time, with nothing structural retaining it for later readback.

GETTEXT needs a live field to query, and there genuinely isn't one here — the same shape as this project's other confirmed structural-reading limits (a PLACETEXT_IN button's baked-in label, layout.gadget's invisible children). Documented in PR #82.

Remaining scope for this issue is now just the one item from my last comment: system-wide requesters with no owning window (disk-swap/DOS-error/Guru) are still detection-only.