[dmitrii-f-t27]

Closes #13326

An OpenCode pane in T27 OS now answers with the owner's NVIDIA keys. Spec at this head: keys.t27, pty_logic.t27, evolve.t27.

Changes

• keys.t27: a fifth profile PR_NVIDIA (base URL https://integrate.api.nvidia.com/v1, models nvidia/nemotron-3-ultra-550b-a55b, then nvidia/nemotron-3.5-super-vl-120b-a12b). Only OpenCode may run it (agent_profile_ok); it has the last rank, so a failing NVIDIA pane never moves to another provider. New agent_first_profile: an OpenCode pane starts on NVIDIA when an NVIDIA key is stored and not marked bad. NVIDIA_API_KEY is first in AGENT_STRIPS. profile_why reads the Claude view of the stored keys. A 429 on NVIDIA gives up; a 401/403 swaps to the next NVIDIA key, then to the second model.
• pty_logic.t27: plan_pane_keys uses agent_first_profile; masks follow (OpenCode 537, Crush 25 unchanged).
• evolve.t27: lane_profile skips profiles its (Claude) agent may not run.
• 13 seals in the Boundary resealed with t27c seal --save built from f863148, no --force.

The key path is master's and unchanged: the PTY server reads the Keychain (ai.t27.os, nvidia, nvidia#2..#8), keeps the key in memory and sets NVIDIA_API_KEY only in the child; OpenCode reads {env:NVIDIA_API_KEY} from OPENCODE_CONFIG_CONTENT. No file and no argv carries a key. Tests use fake values only; grep -rn nvapi- specs .trinity prints nothing.

Requirement -> test

FR	Covered by
FR-001 OpenCode only	agent_profile_ok, agent_stored tests for Claude/Crush/OpenCode with mask 512; evolve lane_profile(512, 0) is none
FR-002 no key value anywhere	config text test ({env:NVIDIA_API_KEY}, no nvapi-, no Bearer); fake values
FR-003 start on NVIDIA, last rank	agent_first_profile cases; next_profile(PR_NVIDIA, ...) is none
FR-004 429 gives up, 401/403 swaps	fo_action / fo_next_model cases; z.ai 429 key swap unchanged
FR-005 Claude why-line and evolve ignore NVIDIA	profile_why(512, 0) has no nvidia; evolve test
FR-006 8 keys	MAX_KEYS unchanged

Verification (t27c/t27b built from f863148, macOS, Apple M1 Pro)

• t27c tests: keys 120/120 (master 115), pty_logic 59/59, evolve 11/11.
• t27b test: pty_server 25/25, glass_window 103/103.
• t27c seal <spec> --verify: all 13 MATCH. check_seal_coverage green.
• Same on this branch and on master f863148, so not caused by this PR: keysync.t27 a_hostile_or_broken_envelope_document_parses_to_nothing (25/26 locally, its seal is left as on master); check_seal_currency 2 analog gen drifts; documented-commands 9 dead tri mentions; make seal-check (NMSE FROZEN_HASH); Corpus ratchet (in tools/red_baseline.txt).
• t27os has no conformance vectors; the executable test blocks play that role.

Limits

• Whether both NVIDIA models answer chat today is not confirmed; the owner checks it live in an OpenCode pane before this leaves draft.
• An OpenCode pane that used z.ai switches to NVIDIA once an NVIDIA key is stored.
• Seven seals outside the Boundary (GodmodeHost, KeysFleet, QueenDash, QueenBoard, Kernel, Share, Kanban) still pin master's closure hashes of the changed specs; master already tolerates stale closure pins and the seal gates pass.

Draft until the owner's live check.

Dmitrii Fedorov (@dmitrii-f-t27)

[dmitrii-f-t27]

Refreshed onto master 085f0d7 (merge 1778d1d, plus 5360f9c resealing master's new importers of keys.t27 and pty_logic.t27: rotation_status, ladder_serve, keys_fleet, godmode_host, ladder_doctor). Seal conflicts were regenerated with t27c built from 085f0d7, never hand-merged. Tests on the merged tree: keys 120/120, pty_logic 61/61, evolve 11/11, rotation_status 10/10, ladder_serve 31/31, keys_fleet 6/6, godmode_host 32/32, ladder_doctor 29/29, all FAIL 0.

Live check passed (local build 7983 = master + this PR + #13207, macOS, owner's own Keychain keys): an OpenCode pane started on nvidia/nemotron-3-ultra-550b-a55b and answered a one-word prompt in 3.2 s; the KEYS panel shows 11 providers, nvidia 8/8 valid; no key value in any T27 OS or OpenCode file. Out of draft.

@gHashTag please merge when CI is green.

Dmitrii Fedorov (@dmitrii-f-t27)