gemu: disasm highlight tracks instruction-start PC (no drift onto operands)

The wasm assembly window centred on the live rPO, which advances mid-instruction
(operand fetch, and jump-target recomputation), so the "current line" highlight
drifted onto operand DB bytes and the next instruction — most visibly across a
jump.

Latch ge->instr_pc in the alpha fetch (state e2/e3), where PO addresses the
opcode and is not advanced within the state. It stays on the executing
instruction while operands are read and PO is recomputed, and only moves when the
next instruction is actually fetched (jumping straight to the target's opcode,
never onto a DB byte). The wasm disassembly window now centres on instr_pc.

Verified over a deck run: instr_pc lands only on real opcodes (07/43/95/92/d2…)
and follows jumps to their targets. Suite 251/251.

Author: danielinux

console/wasm/main.c

@@ -157,10 +157,13 @@ void send_console() {
     set_lamp("LOAD_2",         console.lamps.LOAD_2        );
     set_lamp("OPERATOR_CALL",  console.lamps.OPERATOR_CALL );
 
-    /* gdb-style disassembly window centred on the program counter (PO). */
+    /* gdb-style disassembly window centred on the instruction-start PC
+     * (latched in the alpha fetch), so the highlight stays on the instruction
+     * being executed instead of drifting onto operand bytes / the next line as
+     * the live PO advances mid-instruction (e.g. while computing a jump). */
     {
         static char dis[1536];
-        ge_disasm_window(ge->mem, ge->rPO, 5, 6, dis, sizeof dis);
+        ge_disasm_window(ge->mem, ge->instr_pc, 5, 6, dis, sizeof dis);
         set_disasm(dis);
     }
 }

ge.c

@@ -305,6 +305,16 @@ int ge_run_pulse(struct ge *ge)
         return 1;
     }
 
+    /* Latch the instruction-start PC for the disassembly display. In the alpha
+     * fetch (e2/e3) PO addresses the opcode and is NOT advanced within the state
+     * (operand fetch / PO recomputation happens in the later e0/e4/e6 states), so
+     * this is the address of the instruction now executing. It stays put while
+     * operands are read and PO is recomputed (e.g. across a jump), so a UI
+     * highlight tracking it does not drift onto operand (DB) bytes or the next
+     * line — it only moves when the next instruction is actually fetched. */
+    if (ge->rSA == 0xe2 || ge->rSA == 0xe3)
+        ge->instr_pc = ge->rPO;
+
     msl_run_state(ge, state);
 
     if (ge_clock_is_last(ge)) {

ge.h

@@ -112,6 +112,14 @@ struct ge {
      */
     uint16_t rPO;
 
+    /**
+     * Instruction-start PC (display aid, not a real register). Latched in the
+     * alpha fetch (state e2/e3) to the address of the opcode being executed, so
+     * UI disassembly can highlight the current instruction without drifting onto
+     * operands or the next line as rPO advances mid-instruction.
+     */
+    uint16_t instr_pc;
+
     uint16_t rV1; ///< Addresser for the first operand
     uint16_t rV2; ///< Addresser for the second operand
     uint16_t rV3; ///< Addresser for external instructions using channel 3