[security] test(gateway): cover bridge spawn repro path

[Hinotoi-agent]

Summary

This follow-up strengthens the regression coverage for the remote /bridge spawn shell-execution boundary fixed in #208.

#208 already marks /bridge local-only by default. This PR adds a more reproducible gateway-level test that uses the real default command registry and a concrete marker-file payload, instead of only a synthetic SlashCommand stub.

Security issues covered

Issue	Impact	Severity
Regression coverage for remote /bridge spawn shell execution	Prevents future changes from accidentally re-exposing bridge shell spawning to remote gateway messages	High, matching #208

Before this PR

• [security] fix(commands): keep bridge local-only by default #208 included registry metadata tests.
• [security] fix(commands): keep bridge local-only by default #208 included a gateway denial test using a synthetic SlashCommand object.
• The suite did not directly exercise the real default command registry with a concrete /bridge spawn ... > marker payload.

After this PR

• The gateway test suite resolves /bridge from create_default_command_registry().
• The test sends a concrete remote payload: /bridge spawn printf REMOTE_BRIDGE_EXEC > <marker>.
• The test asserts the remote gateway returns the local-UI-only denial.
• The test asserts no new bridge session is registered and no marker file is written.

Why this matters

The vulnerable behavior in #208 depended on the interaction between default command registration and the remote gateway slash-command gate. A regression test that exercises the real registry path is harder to accidentally satisfy with test-only metadata and better documents the original exploit shape.

How this differs from #208

#208 changed the command metadata and added the initial blocking tests. This PR is intentionally test-only: it improves reproducibility and regression precision after #208 was merged.

Attack flow

Accepted remote channel/gateway user
    -> sends /bridge spawn printf REMOTE_BRIDGE_EXEC > marker
        -> default command registry resolves /bridge
            -> gateway must deny before bridge handler runs
                -> no bridge session and no marker file

Affected code

Area	Files
Gateway regression coverage	tests/test_ohmo/test_gateway.py

Root cause

• [security] fix(commands): keep bridge local-only by default #208 fixed the root cause by making /bridge local-only by default.
• This PR addresses the remaining test gap: the gateway suite should lock in the exact default-registry payload shape that originally reproduced the issue.

CVSS assessment

Issue	CVSS v3.1	Vector
Remote /bridge spawn shell execution regression	8.8 High	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Rationale: this is the same bounded accepted-remote-sender command-execution issue fixed in #208. This PR only adds stronger regression coverage for that boundary.

Safe reproduction steps

I used the same gateway-level harness against the vulnerable base and patched branch:

# origin/main at 380bab4 before #208
REMOTE_INVOCABLE True
REMOTE_ADMIN_OPT_IN False
FINAL Spawned bridge session bridge-... pid=...
BRIDGE_SESSIONS 1
MARKER_EXISTS True
MARKER_CONTENT REMOTE_BRIDGE_EXEC

# patched branch after #208
REMOTE_INVOCABLE False
REMOTE_ADMIN_OPT_IN True
FINAL /bridge is only available in the local OpenHarness UI.
BRIDGE_SESSIONS 0
MARKER_EXISTS False

Expected vulnerable behavior

On vulnerable code, the default registry treats /bridge as remote-invocable and the gateway reaches the bridge handler, spawning a shell process that writes the marker file.

Changes in this PR

• Imports create_default_command_registry() and get_bridge_manager() into the gateway tests.
• Adds test_runtime_pool_blocks_registered_bridge_spawn_without_shelling_out.
• Asserts /bridge resolves from the real default command registry.
• Sends a concrete marker-file /bridge spawn payload through OhmoSessionRuntimePool.stream_message().
• Asserts no new bridge session is registered and no marker file is written.

Files changed

Category	Files	What changed
Tests	tests/test_ohmo/test_gateway.py	Adds default-registry remote /bridge spawn regression coverage

Maintainer impact

• Test-only follow-up.
• No runtime behavior changes beyond [security] fix(commands): keep bridge local-only by default #208.
• Keeps the security boundary easier to review and harder to regress.

Fix rationale

The original vulnerability was reproducible through the real default command registry, so the regression suite should exercise that same route. Checking both bridge-session creation and marker-file side effects proves the command did not merely fail after partially spawning work.

Type of change

• Security fix
• Tests
• Documentation update
• Refactor with no behavior change

Test plan

Executed locally:

• PYTHONPATH=src:. uv run pytest -o addopts='' tests/test_ohmo/test_gateway.py::test_runtime_pool_blocks_registered_bridge_spawn_without_shelling_out tests/test_ohmo/test_gateway.py::test_runtime_pool_blocks_bridge_spawn_from_remote_messages tests/test_commands/test_registry.py::test_bridge_command_is_marked_local_only tests/test_commands/test_registry.py::test_bridge_command_supports_explicit_remote_admin_opt_in -q
• PYTHONPATH=src:. uv run pytest -o addopts='' tests/test_commands/test_registry.py tests/test_ohmo/test_gateway.py -q
• PYTHONPATH=src:. uv run python -m compileall -q src/openharness/commands/registry.py tests/test_commands/test_registry.py tests/test_ohmo/test_gateway.py
• git diff --check
• uv run ruff check src/openharness/commands/registry.py tests/test_commands/test_registry.py tests/test_ohmo/test_gateway.py
• Added-line security scan: no findings
• External reproducibility harness against vulnerable base and patched branch, output included above

Disclosure notes

• This PR is intentionally bounded to test coverage for the already-merged [security] fix(commands): keep bridge local-only by default #208 security boundary.
• No production system was tested.
• No unrelated files are changed.