test(bdd): prototype portable live smoke composition

[sbaum1994]

TL;DR

Prototype a separate target-driven live BDD suite so one portable smoke can run
against an existing local, remote, or production-connected target without
reinstalling the stack for every feature.

Additional Details

The current live entry points couple installation, topology setup, and product
smoke workflows in one large Godog suite. That makes a useful smoke difficult
to reuse against an already installed cluster and encourages more target modes
inside godog_test.go.

This POC adds a separate tests/bdd/live runner with these boundaries:

• A strict, versioned target file supplies non-secret CLI, cluster, and workload
  coordinates. It cannot select features or authorize destructive actions.
• The operator selects one optional provider and one or more smoke files.
  Provider and smoke phases execute explicitly instead of relying on Godog file
  ordering.
• Each smoke is a separate Godog run. Step-exported environment variables and
  ledger-backed files are restored between files, while the built CLI, exact
  CLI state file, and successful bootstrap cache remain suite-scoped.
• BDD_CLEANUP_MODE is rejected because its implementation is specific to
  ncp-local. Every Kubernetes action must expose kubeconfig and context.
• Generic bounded retry, bounded LIFO compensation, strict interpolation, and
  typed JSON-subset assertions are shared through the existing harness and DSL.
  Product validation remains in visible commands and the real CLI/API.

The portable cluster-maintenance feature is the concrete POC for #1186. It
creates and invokes one sample function, proves durable desired and effective
maintenance state, drains the function, uncordons the cluster, and proves the
function becomes active and invokable again. The mutation requires separate
invocation-time consent and uses --expect-cluster-id before changing state.

For the Reviewer

Please focus on tests/bdd/live, the lifecycle-versus-feature ledger split in
harness/suite.go, and the safety contract in tests/bdd/live/README.md.

The issue originally points wiring coverage at godog_test.go. This POC keeps
portable wiring in the new package because the existing file is already large
and owns local install entry points. Existing install features may be selected
as transitional providers, but a future provider should be provisioning-only.

For QA

cd tests/bdd && go test -short ./... passed after rebasing on latest main.

tests/bdd/scripts/lint.sh passed with zero issues.

The destructive live maintenance scenario was not run. No isolated target was
selected for this design POC, and #1186 documents the product regression the
scenario is intended to expose. QA is needed on the local multi-cluster target
after the product fix is available.

Issues

Relates to #1186

Customer Release Notes

Not customer visible.

Plan Summary

No runtime resources change. When explicitly invoked, the POC creates one
temporary sample function and temporarily cordons the selected compute cluster.
Both recovery actions are registered before the cluster mutation.

Usage

See tests/bdd/live/README.md for the target schema, safety contract, attach
mode, and provider-plus-smoke examples.

Notes

This is a draft architecture POC. It deliberately does not auto-detect target
capabilities, skip incompatible features, store credentials in target files, or
hide maintenance behavior in a domain-specific step.

Related Pull Requests

None.

Dependencies

None. The implementation uses existing Go modules. No license review or NOTICE
change is required.

Checklist

• I am familiar with the Contributing Guidelines.
• I have signed off my commits for Developer Certificate of Origin (DCO) compliance.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}