Document call overrides and decompile pitfalls from the locomotor passes

[hrusten]

Adds pitfalls found while typing the locomotor classes in the shared Ghidra database to docs/research/ghidra-workflow.md.

• Stack pops of indirect calls: a typed function pointer does not change the decompiler's guess that the call pops nothing (ActionDeindirect applies the prototype after the stack analysis). A user CALL_OVERRIDE_UNCONDITIONAL reference does.

• Locomotor overrides: the Virtual-call references section now lists where the database carries these overrides since 2026-10-06:

  • calls through a locomotor's own vtables;
  • owner calls through slots that UnitClass, InfantryClass, AircraftClass and FootClass share;
  • calls through cells from the map's cell getters.

  It also explains why per-call signature overrides can't be written through GhidraMCP: they need a label in the override namespace, and create_label writes only global labels.

• Decompile reading:

  • this[-1] in view-typed methods;
  • pLinkedTo[1] for AircraftClass fields;
  • a reused this stack slot;
  • the x87 expression dropped before _ftol.

• GhidraMCP writes:

  • set_function_prototype renames default-named functions;
  • it writes void * silently for unknown pointer types;
  • create_function_signature stores no calling convention or parameter names;
  • PRE comment placement.

Evidence level: the database behaviour was observed on the staging copy and the live server (Ghidra 12.1.2, GhidraMCP 5.14.2). The ActionDeindirect and override-namespace claims come from the Ghidra 12.1.2 sources: coreaction.cc, HighFunctionDBUtil.writeOverride and GhidraMCP's SymbolLabelService.createLabel.

Validation: docs only; the new section link resolves to the existing heading. No Cargo run.