Generalize deferred onboarding for additional agent runtimes

## Problem Statement

Issue #10288 limits deferred onboarding to Hermes. Other supported agent runtimes can later require the same separation between software installation and credential-dependent onboarding.

A separate installer branch for each runtime would duplicate lifecycle behavior. A global behavior would also be incorrect because each runtime has different onboarding, credential, provider, and sandbox requirements.

## Desired Behavior

After #10288 merges, define one runtime-neutral deferred-onboarding contract for additional supported agent runtimes.

- Select at least one accepted non-Hermes agent runtime as the second current consumer.
- Let each supported agent runtime opt in through its existing runtime ownership.
- If the required provider credential is present, run that runtime's normal validated onboarding.
- If the credential is absent and deferred onboarding is enabled, install the runtime without creating a provider or sandbox and without reporting onboarding as complete.
- If the credential is invalid, fail onboarding. Do not treat an invalid credential as absent.
- Let the existing onboarding command complete setup after the credential becomes available.
- Keep current behavior unchanged for agent runtimes that do not opt in.
- Let future accepted agent runtimes adopt the same contract without adding another installer flow.

## Constraints and Non-goals

- Depends on #10288. Do not generalize the behavior before the Hermes contract merges.
- The first implementation must include one accepted non-Hermes runtime. Do not create an abstraction for hypothetical consumers only.
- Do not add a general inference-validation bypass.
- Do not create a parallel onboarding state machine, installer path, runtime registry, or test harness.
- Do not require different agent runtimes to share provider-specific credential rules.
- Do not create placeholder providers, credentials, or sandboxes.
- Do not persist provider credentials in image layers, command arguments, logs, or onboarding state.
- Each additional runtime requires accepted ownership, lifecycle, compatibility, security, and validation expectations.

## Implementation Idea

After #10288 merges, compare the Hermes behavior with the selected additional runtime. Extract only the semantics that both current consumers require.

Extend the existing installer, agent-runtime ownership, onboarding functions, and installer integration tests. Keep provider-specific and runtime-specific behavior in their current owners.

Add focused tests for:

- the Hermes behavior from #10288 remains unchanged;
- the selected additional runtime installs without a provider or sandbox when its credential is absent and deferred onboarding is enabled;
- a present valid credential runs normal validated onboarding;
- a present invalid credential fails onboarding;
- an agent runtime that has not opted in keeps its current behavior;
- runtime onboarding can complete after a credential becomes available;
- credential values do not appear in image layers, command arguments, logs, or saved state.

## Category

Feature

## Checklist

- [x] I searched existing issues and this is not a duplicate
- [x] I described the problem and desired behavior

After #10288 merges, compare the Hermes behavior with the selected additional runtime by reading the existing installer, agent-runtime ownership, and onboarding functions. Run the installer integration tests and add focused coverage for deferred, valid, invalid, non-opted-in, completion, and credential-leak behaviors; done means the shared contract works without changing non-opted-in runtimes.

Written by the indexing model from the issue text.