targeting: say what you are about to hit or throw at

Both aiming modes announced their name and then went silent, so there was
no way to know what the arrow keys were pointing at. Prompted by "it says
targetting, melee, but when I press the arrow keys it does not tell me
what I am currently selecting."

They look like a pair and are not, which is the whole shape of the fix.

Throw has a real free-roaming cursor on level.cursorX/cursorY, so its
descriptor is ingame_observe plus one clause: whether the tile is a legal
target. That clause is recomputed from level.FoV, level.interactableArea
and level.canThrowOnCell rather than read off the state's targetAllowed
upvalue, because ingame_targeting_throw.lua:228 sets targetAllowed false
for the whole 0.3s cursor glide and only the animation's onFinish
restores it -- and mid-glide is exactly when we speak, so it would have
said "blocked" on every single move. The same class of trap as the
examine-cursor popup lag, and the same answer: read the model, not the
view.

Melee has no cursor and no target state at all.
ingame_targeting_melee.lua:184-195 takes one direction key and fires the
callback in that same keypress, so nothing is ever "currently selected"
and there is no focus for a read() to return. Its descriptor speaks only
on entry, listing the eight adjacent tiles -- which are precisely the
legal targets, the game's rule being Chebyshev <= 1. Arrows still commit
immediately; the game plays as it did. A two-step confirm cursor was
considered and rejected for that reason.

That entry line is surroundings.scan()'s sentence, so scan() splits into
describeNeighbours() returning the text and scan() speaking it. onOpen
grows the ability to be a function rather than a fixed string, since the
neighbours differ every time.

menus.selfTest needed a branch for a descriptor with neither read nor
probe -- melee is the first -- or it would index a nil probe and take the
whole self test down with it, which is the one report that must never
fail quietly.

Neither mode is reachable by its key in the prologue: b is filtered out
by the room's level.allowedActions, and t falls through to
gotoInventory() when there is nothing throwable. Found that by writing
the testbed block as keypresses and watching it land in the inventory. It
now drives both states directly, borrowing levelWindow, hpbar and
levelDescriptionWindow off the ingame state's upvalues the way gotoAction
would pass them.

129 testbed checks, 0 failures. The throw block asserts the focus text
CHANGED across a cursor move rather than merely being non-nil, which is
the assertion that would have caught the targetAllowed mistake had it
been made. Still unverified against real content: only "can throw" has
been heard, not "blocked", "out of range" or "no line of sight".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

accessibility/docs/scratch.md

@@ -7,7 +7,7 @@ fixing what Talon hits. Remaining work is polish, mod settings and distribution.
 
 **Game is playable start-to-finish by ear** from main menu through the intro
 conversation into gameplay, plus journal, character, actions and inventory —
-verified by the testbed, **120 checks, 0 failures**.
+verified by the testbed, **129 checks, 0 failures**.
 
 **Not set up yet, or unsure how the two trees relate?** →
 [00-dev-setup.md](00-dev-setup.md).
@@ -282,7 +282,13 @@ where you're standing now. `playing` is cleared on level change.
   (`terse`/`normal`/`verbose`) since sweeping 8 neighbours and inspecting one
   tile want different amounts of detail.
 - `accessibility/states/ingame_observe.lua` — narrates the game's examine cursor.
+- `accessibility/states/ingame_targeting_throw.lua` — narrates the ranged
+  targeting cursor, plus whether the tile is a legal target.
+- `accessibility/states/ingame_targeting_melee.lua` — speaks the eight adjacent
+  tiles on entry. **No `read()`, by design** (see below).
 - `accessibility/surroundings.lua` — probe/scan/where-am-I without moving.
+  `describeNeighbours()` returns the eight-neighbour line; `scan()` speaks it and
+  melee targeting reuses it.
 - `accessibility/patches/popups.lua` — wraps `inventoryCursorPopup.set`, covering
   **inventory, craft, refine, trade** in one patch.
 
@@ -301,6 +307,38 @@ therefore deliberately **not** patched; only `inventoryCursorPopup` is.
 *(The level model is a closure instance, not a module, so it can't be patched at
 require time — reading its public fields is the decoupled route.)*
 
+#### Design note: the two targeting modes are not symmetrical
+They look like a pair and are not.
+
+**Throw** (`states/ingame_targeting_throw.lua`) has a real free-roaming cursor on
+`level.cursorX/cursorY`, so its descriptor is `ingame_observe` plus a validity
+clause. ⚠ **Do not read the state's `targetAllowed` upvalue** for that clause:
+`throw.lua:228` sets it `false` for the whole 0.3s cursor glide and only the
+animation's `onFinish` restores it, so mid-glide — which is exactly when we
+speak — it always says "blocked". Recompute instead from the same three public
+inputs the game uses (`throw.lua:86-89`): `level.FoV`, `level.interactableArea`,
+`level.canThrowOnCell`.
+
+**Melee** (`states/ingame_targeting_melee.lua`) has **no cursor and no target
+state at all**: `melee.lua:184-195` takes one direction key and fires the
+callback in that same keypress. Nothing is ever "currently selected". Its
+descriptor therefore has no `read()` and speaks only on entry, listing the eight
+adjacent tiles (which are precisely the legal targets — the game's rule is
+Chebyshev ≤ 1, `playerActions.lua:3-6`). A future reader should not "fix" the
+missing `read()`; there is nothing for it to return. A two-step confirm cursor
+was considered and rejected: it would change how the game plays.
+
+⚠ `menus.selfTest` had to grow a branch for descriptors with neither `read` nor
+`probe` — melee is the first — or it would index a nil `probe` and take the
+*whole* self test down with it.
+
+⚠ Neither mode is reachable by its key in the prologue: `b` (hit) is filtered out
+by the room's `level.allowedActions`, and `t` (throw) falls through to
+`gotoInventory()` when there is nothing throwable
+(`states/ingame.lua:986-990`). The testbed drives both by `states.switch`,
+borrowing `levelWindow`/`hpbar`/`levelDescriptionWindow` off the `ingame` state's
+upvalues the way `gotoAction` would.
+
 #### Testability seam
 `hotkeys.isCtrlDown` / `isShiftDown` are overridable fields, not direct calls to
 `love.keyboard.isScancodeDown`. Real hardware state can't be faked by
@@ -378,7 +416,8 @@ yet. Verify against a later area before trusting those two categories.)*
 `init.lua`, all resolving in the startup self-test:
 
 `main_menu` · `settings_menu` · `load_game` · `new_game` · `narration` ·
-`ingame_dialogue` · `ingame_observe` · `actions_menu` · `worldmap` ·
+`ingame_dialogue` · `ingame_observe` · `ingame_targeting_melee` ·
+`ingame_targeting_throw` · `actions_menu` · `worldmap` ·
 `alchemy_table` · `journal` · `character` · `inventory` ·
 `menu_text` / `ingame_message` / `menu_message` (shared `_textscreen.lua`)
 
@@ -1000,6 +1039,10 @@ require trap as the research tree.
   announcements (`popupStack.add`), damage alerts
   (`ingame.checkInterruptions`), mod settings.
 - `ingame` itself has no descriptor.
+- **Targeting is verified only against the prologue room**, where neither mode is
+  reachable by its own key and the testbed drives them by `states.switch`. The
+  throw descriptor's "out of range" / "no line of sight" / "blocked" branches
+  have not been seen against real content — only "can throw".
 - **Unverified against real content:** tracker categories Items / Alchemy /
   Exits / Creatures / Terrain (tutorial house has none), and inventory item
   names (inventory is empty in the prologue).