port: OPTIONS is reachable from the main menu

main_menu ptbtn04 had goto:null and blocked:'GP_OPTIONS not in this export'.
GP_OPTIONS is in the export now, entry 19 is its root, and the walk works:
main_menu -> down x3 -> (A) -> the OPTIONS root renders, (B) backs out. A dead
button became a real screen.

🔴 Navigation INSIDE it does not work, and that is a decode question. The
exporter's detector is kind==0x3002 && !focused; the OPTIONS rows are 0x3003, so
role is unknown and buttons[] is empty. Not widened here -- what 0x3003 means is
the Decoder's. The circumstantial case is strong and circumstantial is exactly
the standard that has cost this project three retractions. A rule of 'has a focus
record therefore is a menu item' fits both screens and is still an inference
about semantics from structure; not taken.

Also recorded: a screen NAME only reaches the port through a full re-export,
which re-transcodes both movies -- renaming one screen costs the whole tree.

🔴 And a dangerous mistake: pkill -f 'check-all' matched the CONTAINER ENTRYPOINT,
whose command line contains the loop prompt, which mentions check-all. pgrep then
reported the job still running after it had stopped, and pkill -9 on that pattern
could have killed the session. Match on comm or list with ps and check first --
a pattern that appears in your own instructions does not identify a process.

docs/port/options-screens.md

@@ -42,3 +42,52 @@ anything beyond `main_menu → options` needs the real navigation.
 * **All 14 are `NEVER COMPARED`** by `verify-screen` — reported, not asserted;
   both its allowance and the reference renderer were calibrated on `GP_TITLE`.
 * The screens are static: no navigation, no focus movement, no value editing.
+
+---
+
+# ✅ OPTIONS is reachable — and navigation inside it is blocked on a kind
+
+`main_menu` `ptbtn04` now has `goto: "options"`. Walked with the menu harness:
+main_menu → ⬇⬇⬇ → Ⓐ → the OPTIONS root renders. Ⓑ backs out.
+
+## 🔴 The rows do not move, and the reason is a decode question
+
+The exporter's button detector is `kind == 0x3002 && !focused`. The OPTIONS rows
+are **`kind_raw = 0x3003`**, so `role` comes out `unknown`, the export's
+`buttons[]` is empty, and up/down move nothing.
+
+| screen | element | kind | focus record | in `buttons[]` |
+|---|---|---|---|---|
+| `main_menu` | `ptbtn01` | `0x3002` | yes | yes |
+| `extras` | `ptbtn11` | `0x3002` | yes | yes |
+| **`options`** | **`po_menu_btn1`** | **`0x3003`** | **yes** | **no** |
+
+**What `0x3003` means is not the port's to decide**, so the rule was not widened
+here. The circumstantial case is strong — five rows, each carrying a focus
+record, on a screen whose own text lists five options — and *circumstantial* is
+precisely the standard that has cost this project three separate retractions.
+Asked of the Decoder.
+
+⚠️ A tempting alternative rule is "an element with a focus record is a menu item",
+which fits both screens. It is still an inference about semantics from structure,
+and it would silently reclassify elements on every screen in the export. Not
+taken.
+
+## The workflow cost this exposed, worth knowing before repeating it
+
+**A screen name is authored data, but it only reaches the port through a full
+re-export** — which re-transcodes both movies. Renaming one screen costs the
+whole tree. Not worth fixing today; worth knowing before anyone plans a naming
+pass.
+
+## 🔴 And a genuinely dangerous mistake, recorded because it nearly cost the session
+
+Killing a background check with `pkill -f "check-all"` matched **the container's
+own entrypoint**, whose command line contains the loop prompt — and that prompt
+mentions `check-all`. `pgrep` duly reported the process as still running after it
+had stopped, and a `pkill -9` on that pattern could have killed the session
+itself.
+
+**Match a process by its actual `comm`, or list with `ps` and check, before
+sending a signal.** A pattern that appears in your own instructions is not a
+pattern that identifies a process.