feat(tmachine): support runtime input overrides

从 tmachine 的 install 和 test 命令入口以及 issue 中描述的 config.yaml 输入处理开始。跟踪安装程序输入如何被规范化、纳入安装层哈希并传递给 Ansible。为解析、优先级、验证和缓存失效添加单元测试；完成的标准是两个命令都接受可重复指定的覆盖项，并且 Debian conformance lane 使用不可变的候选镜像引用，而不使用固定的 :tmachine 标签。

User Story

As an integration-test author, I want to override named tmachine inputs at runtime, so that CI can test candidate artifacts using values that are known only when the workflow runs.

Problem Statement

Tmachine inputs are currently fixed in its generated YAML configuration. The install and test commands have no runtime input override, even though release-specific values such as the candidate image SHA are available to the workflow only at runtime.

The Debian conformance lane introduced in #3461 therefore loads candidate supervisor and sandbox images under the fixed :tmachine tag and writes those references into the test user's gateway configuration. This safely prevents the packaged gateway from resolving its embedded dev or release-version tag, but it hides the candidate image identity and couples the playbook to a synthetic tag.

Using the package's embedded image tag is not a safe replacement. Release Dev could refresh :dev from the registry and test an older published image, while Release Tag runs before the versioned images are published.

Impact / Why This Matters

The current fixed-tag override keeps conformance deterministic, but CI cannot express the actual candidate image tag through tmachine. That makes artifact provenance less obvious and creates a risk that a future cleanup removes the override and accidentally pulls a previously published image during release validation.

Regenerating the Nix-backed tmachine configuration for every workflow value would move runtime CI data into build-time configuration and make local reproduction unnecessarily difficult.

Proposed Design

Add a repeatable runtime --input NAME=VALUE option to the tmachine install and test commands. Runtime values should override matching configured inputs before tmachine hashes the install layer and invokes Ansible.

The resulting workflow should allow release CI to retain the candidate images' immutable source-SHA tags and invoke tmachine with an override such as:

tmachine test ubuntu-docker-rootful deb conformance \
  --input openshell_runtime_image_tag="$SOURCE_SHA"

The Debian installer can then write the source-SHA image references into its minimal per-user gateway configuration. The packaged systemd unit and all other built-in gateway defaults remain unchanged.

Acceptance Criteria

• tmachine install accepts repeatable --input NAME=VALUE overrides.
• tmachine test accepts the same overrides for the installer phase.
• Runtime values take precedence over matching installer inputs from config.yaml.
• Malformed overrides and unknown input names fail with actionable errors.
• Effective override values participate in the install-layer cache key.
• Existing file-path inputs continue to be canonicalized when the referenced file exists, while scalar values do not need to name an existing file.
• Unit tests cover parsing, precedence, validation, and cache invalidation.
• Release Dev and Release Tag can pass the candidate source SHA to the Debian installer and remove the fixed :tmachine image references.
• The Debian conformance lane continues to use a local immutable candidate image and does not pull dev or release-version runtime images from the registry.

Alternatives Considered

• Keep the fixed :tmachine alias. This is deterministic but obscures which candidate image is under test and leaves the workflow coupled to a synthetic name.
• Use the image tag embedded in the packaged gateway. This can pull an older dev image, and versioned release images are not published until after conformance succeeds.
• Generate a new tmachine configuration in CI. This mixes runtime workflow values into Nix evaluation and makes equivalent local invocations harder to reproduce.

Agent Investigation

Tmachine currently stores installer and testsuite inputs as BTreeMap<String, PathBuf>. Existing paths are canonicalized before becoming Ansible extra variables; nonexistent paths are already passed through as literal values. Installer inputs are also part of the cached install-layer hash, so runtime overrides must be applied before both hashing and playbook execution.

Related to #3454 and follow-up to #3461.