test(bdd): add readable TLS listener probe DSL

Why

The secure registration feature uses inline Bash for two repeated operator-visible probes: validating the TLS listener with the issued CA and confirming that a plaintext Watch request is rejected. The commands are precise but make the feature harder to read and maintain.

Scope

Explore shared BDD steps for these probes. The DSL must keep the endpoint, TLS authority, CA source, timeout, and expected externally observed result visible in Gherkin. It may hide only shell and output-format mechanics.

The implementation must preserve raw-command assertions as the escape hatch for uncommon cases and must not move product validation, result normalization, or failure suppression into step handlers.

Acceptance criteria

• The secure-registration feature no longer embeds Bash to run the common TLS listener and plaintext rejection probes.
• The feature exposes all meaningful user inputs and expected outcome.
• Focused unit and wiring coverage verifies the new steps retain the real command result.
• Existing product-level TLS and plaintext-rejection evidence remains intact.

Start with the secure-registration feature and locate its two inline Bash probes, then trace the existing BDD step definitions and raw-command assertion path. Check how focused unit and wiring coverage exercise step handlers. Done means the common probes are expressed readably in Gherkin, meaningful inputs and outcomes remain visible, raw-command assertions still work, and product-level evidence is unchanged.