feat: standardize timeout environment-variable semantics

User Story

As an OpenShell operator or automation author, I want timeout environment variables to have consistent, documented zero and invalid-value behavior, so that configuration does not unexpectedly cause commands to fail immediately or wait forever.

Problem Statement

OpenShell exposes timeout environment variables with inconsistent parsing and zero-value semantics. For example, OPENSHELL_PROVISION_TIMEOUT and proposed OPENSHELL_LIFECYCLE_TIMEOUT parse 0 as an immediate deadline, OPENSHELL_BUILD_NO_PROGRESS_TIMEOUT_SECS falls back to its default for zero or invalid values, OPENSHELL_VAULT_TIMEOUT_SECS rejects zero, and the local Helm collector timeout passes 0s to kubectl rollout status, where it means wait indefinitely.

This makes it difficult to safely configure automation and obscures whether zero means disabled, immediate, default, or unlimited.

Impact / Why This Matters

Operators must infer each variable's contract from implementation details. A copied value such as 0 can cause a CLI workflow to fail immediately or a local cluster setup to block indefinitely. Invalid values also vary between being silently ignored and causing a clear error, making configuration mistakes harder to detect.

Proposed Design

Define and document a shared timeout environment-variable contract for OpenShell-owned tooling. For each timeout setting, specify its unit, default, valid range, behavior for zero, and behavior for invalid or out-of-range values. Apply the chosen contract consistently where practical, while retaining an explicitly documented exception only when the underlying dependency imposes a different meaning.

Acceptance Criteria

• The project has a documented timeout environment-variable convention covering units, defaults, zero, invalid, and out-of-range values.
• The contract is applied or an explicit exception is documented for OPENSHELL_PROVISION_TIMEOUT, OPENSHELL_LIFECYCLE_TIMEOUT, OPENSHELL_BUILD_NO_PROGRESS_TIMEOUT_SECS, OPENSHELL_VAULT_TIMEOUT_SECS, OPENSHELL_STOP_TIMEOUT, and HELM_K3S_COLLECTOR_HEALTH_TIMEOUT.
• CLI-facing timeout environment variables reject invalid configuration with actionable errors, or deliberately and consistently fall back with that behavior documented.
• Automated tests cover the selected zero and invalid-value behavior for affected OpenShell-owned timeout parsing.
• User-facing CLI and deployment documentation states the selected semantics.

Alternatives Considered

Leave each timeout setting to its owning component. This preserves existing behavior but keeps configuration surprising across adjacent workflows and makes automation less portable.

Agent Investigation

• OPENSHELL_PROVISION_TIMEOUT=0 produces an immediate provisioning-idle timeout.
• PR #3001 introduces OPENSHELL_LIFECYCLE_TIMEOUT with the same parsing pattern and therefore the same zero behavior.
• OPENSHELL_BUILD_NO_PROGRESS_TIMEOUT_SECS accepts only positive parsed values; zero and invalid values use the 1800-second default.
• Vault validation rejects non-positive timeout_secs.
• kubectl rollout status --timeout=0s waits indefinitely, so the Helm local-development setting has distinct zero semantics.

Start by tracing parsing and validation for the named timeout environment variables, including the lifecycle pattern introduced by PR #3001, and inspect the existing CLI, deployment documentation, and automated tests. Done means the convention covers units, defaults, zero, invalid, and out-of-range values; affected variables follow it or document exceptions; and tests and user-facing documentation reflect the chosen behavior.