Verify provider profile imports for the OpenShell upgrade #12940

Problem

The intended OpenShell upgrade uses an import-only provider-profile catalog. A fresh gateway starts with an empty catalog and requires an explicit profile import before a provider can use that profile. NemoClaw already imports and verifies several checked-in profiles, but an overlooked onboarding, credential, or sandbox path could still depend on an OpenShell built-in profile or alias.

Parent epic: #12558. This ticket prepares the existing provider workflows for the import-only catalog. The OpenShell pin change remains outside this ticket.

Outcome

Every supported NemoClaw provider path has an explicit, owned profile definition before it creates or attaches a provider. Repeated setup verifies the existing profile. A conflicting profile fails before provider or sandbox mutation.

Scope

• Inventory profile IDs used by supported onboarding, credential, inference-selection, restart, rebuild, and sandbox-creation paths. Include the paths delivered by Slice 2: Move remaining fixed hosted providers to native inference #12589 and Slice 3: Move user-supplied hosted endpoints to native inference #12636 when they land.
• Map each used ID to a NemoClaw-owned definition and its import point. Remove any reliance on built-in catalogs, implicit aliases, or command-based provider selection.
• Reuse the existing import, export, and contract-check mechanisms. Ensure import precedes provider creation or attachment for each path.
• Keep profiles in the accepted NemoClaw workspace scope. Preserve endpoint, executable, and credential restrictions.
• Report a missing or conflicting profile with a bounded action message. Do not replace an operator-owned profile or expose credential values.
• After provider creation or attachment, re-export the profile on a best-effort basis. If a successful export differs from the definition verified before mutation, warn that the catalog changed and NemoClaw cannot confirm which definition was used at bind time. If the export fails or times out, warn that post-mutation verification did not complete and ask the gateway operator to inspect the profile. Keep warnings free of credential values and continue setup without rollback solely because of a post-mutation warning. Keep pre-mutation mismatches blocking.

Acceptance evidence

• A fresh gateway with an empty profile catalog can set up one representative existing provider and attach it to the intended sandbox after importing its profile.
• A repeat setup with the same profile definition succeeds by checking the existing definition.
• A profile ID collision with different contents stops before provider or sandbox mutation and preserves the existing profile.
• A missing profile or failed import cannot be reported as successful provider setup.
• Focused tests cover the import ordering, repeat run, collision, and failure behavior. One disposable smoke run on the selected target OpenShell release verifies import, provider creation, and attachment without changing the repository pin.
• The inventory records each supported profile ID, its checked-in definition, the path that imports it, and any remaining gap.
• A focused test shows that a detected post-mutation mismatch produces the warning without changing the operation's result. The warning contains no credential values and does not claim atomic protection.
• A focused test shows that a failed or timed-out post-mutation export produces a credential-free recovery warning without changing the operation's result.

Boundaries

Use #12558's accepted provider scope and security rules. Coordinate with #12589 and #12636 so this ticket checks their completed paths rather than duplicating their profile implementation. Do not add providers, a bulk profile manager, an OpenShell dependency update, or automatic migration of existing beta sandboxes. If a required path lacks an owned profile or needs broader access, stop and resolve that scope decision before implementation.

OpenShell change: NVIDIA/OpenShell#3383