The exec row rebuilt an `import base64; exec(base64.b64decode(...))` string only to feed it back
through the base64 row; decoding the payload directly is shorter and leaves no line that reads like
the base64+exec payload signature the supply-chain scan (rightly) refuses. The test derives the two
re-entry forms from the existing launcher forms instead of re-spelling the cmd-launcher source.
When a launch through the published -c launcher (POSIX shell or Windows .cmd) syncs dependencies
first, venv_sync.relaunch_command re-execs it as `python -I -c "...; sys.argv = [...]; exec(<launcher
source literal>)"`. _BOOTSTRAPS covered the run_module/run_path re-entries but not this exec branch, so
the gateway it started was invisible to every canonical reader: live_gateway_pid_for_home, the fleet
restart, the stale-survivor sweep and update inventory. The new row matches the launcher in place by its
own anchors (readers normalize the literal escapes, so decoding it cannot work) and recurses into the
base64 row for the .cmd form. Extends the #124318 identity table and its test.
gateway/status.py grew past main's size (code-health FILE_LINES). Move the
cohesive `python -c <src>` parsing group -- inline_source_flag_index,
command_line_runs_inline_source, the Hermes bootstrap patterns,
_bootstrap_entry and inline_bootstrap_argv -- verbatim into the new sibling
gateway/status_inline_source.py (no imports of the facade, so no cycle).
status.py imports the three names it uses; the one external caller
(hermes_cli/update_cmd_windows.py) now imports from the sibling. No shim,
no docs named the symbols. Behaviour unchanged.
