test(e2e): pin regression coverage for verified-but-unpinned CLI behaviours (EAI-8072)

[fredespi]

Summary

Adds end-to-end regression scenarios that pin CLI behaviours which were manually verified as correct during the walkthrough but had no automated test guarding them. Everything here runs on the no-GPU/no-network mock lane (every PR) and asserts host-invariant contracts (exit code + stable output), so a regression surfaces in CI rather than in the field. Contracts were grounded by running the real Linux rocm binary, not read from source.

Relates to EAI-8072 (linked from EAI-8024, EAI-7409, EAI-7404).

Changes

New feature files and step definitions:

• config — set/clear default engine and runtime; telemetry and permissions modes; set-engine requiring a target; provider enable/disable; the local provider not being toggleable as a cloud provider; and saving a provider key failing without leaking the key when secure storage is unavailable.
• logs — --search reporting the matching-line count, an absent term reporting no matches, and the --service/--search conflict being refused.
• automations — enabling/disabling a watcher confirms its mode; enabling an unknown watcher is refused. (The background daemon spawn is suppressed in-test so nothing leaks.)
• runtime lifecycle — activate records the previous runtime, rollback returns to it, uninstall of an externally-sourced runtime keeps its folder, and import rejects a duplicate unless --replace. Driven with planted read-only runtimes, so no SDK download or GPU is needed.
• update — the report distinguishes configured from not-configured update feeds (run with no managed runtimes so it stays offline).
• networking — binding to a public interface without --allow-public-bind is refused pre-flight (the EAI-7409 contract).
• serve — --runtime-id and --env-id are rejected as a mutually-exclusive selector conflict.

Also adds a small run_rocm_with_stdin test helper (stdin + extra env) for commands that read from stdin.

Test plan

• Full e2e cucumber suite green on a native-Linux container (mock lane): all new scenarios pass; reconciliation shows only the pre-existing engine-shell-marks-the-prompt host-environment failure, which also fails on unmodified main in the same container and is green on CI's runner.
• cargo clippy --tests clean under -D warnings.
• CI mock lane green on this PR.

Scope

This PR covers the mock-lane (no-GPU) regression set. The remaining GPU-only behaviours from the ticket (public-bind live auth/401, serve selector effects reflected in the serve plan, --tool-call-parser, --no-smoke-test) require a live GPU serve to validate and are tracked separately.

[tomastola]

The new runtime lifecycle fixtures are not portable to Windows.

plant_runtime writes registry entries with:

registry.join(format!(\"{key}.json\"))

The keys contain : (for example, therock-release:gfx942). On Windows, that creates an alternate data stream rather than a normal registry file, so the CLI cannot discover the planted runtime. The Windows E2E lane consequently has three unexpected failures:

• runtime-activate-records-previous
• runtime-rollback-returns-to-previous
• runtime-uninstall-keeps-external-folder

All fail with installed runtime not found: therock-release:gfx942.

Please create these fixtures through a platform-safe path—preferably rocm runtimes import, which already passes on Windows and preserves the suite's black-box design—or use the same platform-safe filename encoding as production. These scenarios should not simply be skipped on Windows because the covered runtime operations are intended to be portable.

[fredespi]

Thanks @tomastola — good catch, fixed in c05b931.

Root cause was exactly as you described: the fixtures wrote registry entries at <runtime_key>.json using a therock-release:gfx942-style key, and the : names an NTFS alternate data stream on Windows, so the planted file was never a discoverable registry entry.

The fix uses production-shaped keys. Production derives runtime_key by slugifying (runtime_key() in therock.rs), so a real key is filename-safe on every OS. The fixtures now use the slugified form (release-tarball-gfx942) and keep the therock-release:<family> identifier only in runtime_id, which is a manifest field value and never a filename. This is the "same platform-safe filename encoding as production" path — it keeps the scenarios as GREEN black-box coverage of the portable runtime operations rather than skipping them on Windows. I also added an assertion in the planting helper so a future key that isn't filename-safe fails loudly instead of silently breaking one platform.

Verified the four runtime lifecycle scenarios still pass on Linux; the Windows E2E lane on this push should now find the planted runtimes.

[tomastola]

Fix confirmed — keys now match production's slugify("{channel}-{format}-{family}") shape rather than a hand-picked safe-looking string, and the guard in plant_runtime keeps it that way. Windows lane green. Thanks.