Dev oracle run across all providers

## Requirement Original requirement (epic, verbatim): "Add support for GCP and Azure with the same functionality as AWS: - Your Cloud (former Your AWS) - NodeLink may work on GCP and Azure - What else we have AWS specific Out of Scope: Jaah Hosted (still remains AWS only)" PRD (verbatim): "Every oracle below is a real flow on the dev CP in a browser unless it says otherwise." … "Acceptance flows in R3–R7 run after the operator fills them." ## Scope (Architecture C5 part 2) — verification only, no code After `jaah/test/gcp` and `jaah/test/azure` are filled (check Settings › Credentials › Test passes; if still placeholders, ASK once with header `Credential` naming both, then run everything not blocked — the AWS regression — and settle with the GCP/Azure remainder named), run on the dev CP (`app.dev.jaah.ai`) in a browser, through the console only (N9), on GCP, Azure and AWS: - AC1.1 Settings › Credentials › Add offers "GCP" and "Azure"; saving a valid key and pressing Test shows success; an invalid/revoked key shows the provider's own error text, never the secret. → verify: on dev CP add each type with the operator's real key and with a deliberately wrong secret; observe pass and the readable refusal. - AC1.2 No secret value appears in any API response, log line, or the credential list. → verify: open the saved credential's edit form (secret fields empty/masked), and `GET` the credential via the console's network tab — no secret field value. - AC2.1–AC2.4 (card text, footer per provider, connection per provider with blank network → reopen shows resolved values, picker gating as a tenant with GCP off). - AC3.1 From Add node › Your Cloud, choosing a GCP (then an Azure) connection and an allowed machine type launches an Ubuntu VM (same Ubuntu release AWS uses) in the customer's account; the node appears in Machines, reaches online (daemon connected over the tailnet) and can run a task. → verify: on dev CP launch one node per provider, dispatch a trivial task to it, observe it complete. - AC3.2 Node detail on a GCP/Azure node offers the same actions an AWS node offers today — stop, start, change machine type, grow disk, delete — and each takes effect in the provider (observed in the provider console) and in Machines. Delete removes the VM and its disk. → verify: perform each action on each provider's node. - AC3.3 (dev half) launch with an invalid machine type and observe the readable refusal and no stray node row. - AC3.4 AWS behaviour is unchanged: an AWS launch, stop/start, resize, delete still pass. → verify: repeat AC3.1–3.2 on an AWS connection on dev CP. - AC4.1 With `windows_nodes_allowed` ON, the OS control offers Windows on GCP/Azure connections for machine types that run it; the Windows node launches, its Jaah service connects and it runs a task. With the switch OFF, Windows is not offered on any provider. → verify: dev CP launch per provider; flip the switch on a tenant and observe it disappear. - AC5.1/AC5.2 browse GCP and Azure regions on dev CP; allow two types each; observe them in the Add node type picker for that provider. - AC6.1 create one storage per provider on dev CP; AC6.2 attach to two nodes, log an account in on one, observe it usable on the other; AC6.3 read the create form; AC6.4 try a cross-cloud attach. - AC7.1 on a dev node stop the Jaah daemon, then open a shell through the provider's console; AC7.2 mark a GCP and an Azure node MicroVM, dispatch a task, observe it run in a VM; AC7.3 inspect the VM, disk, firewall/NSG and storage in each provider console for the labels/tags. Viewing provider-side resources (AC3.2, AC7.1, AC7.3) uses the provider's own console with the human operator if this runner cannot reach it — ASK once (header `Access`), and record what the operator observed. For every failure: if trivial and in-scope, still do NOT fix here — file ONE follow-up Task per topic with itemized 1–2 sentence requirements (project directive), linking the evidence. Clean up every test VM, disk and storage created (delete through the console) and confirm nothing billable remains. Credentials & reach: All browser oracles (AC1–AC8) on dev CP | `jaah/debug/main/operator-login` (operator; switches to tenants), dev CP `app.dev.jaah.ai` | **verified** (Architect stage: credential_get succeeded, real sign-in, value not recorded). GCP oracles | `jaah/test/gcp` | **deferred** until the operator fills it (operator D6). Azure oracles | `jaah/test/azure` | **deferred** until filled (operator D6). AWS regression | `jaah/test/aws` from roster `gmind/system/gmind-aws` | **verified** for the Architect stage; created by the "Dev credential stubs" child. Out of scope: Do NOT change code or open a PR (follow-up Tasks only). Do NOT touch Jaah Hosted (N1), prod, node groups/Spot (N4), federation (N5), cross-cloud NodeLink beyond the refusal check (N6), macOS (N8). Never use a CLI, raw API call or SQL against the CP (N9). Never record a credential value. Done means: - Every oracle listed above has a PASS/FAIL row per provider (GCP, Azure, AWS) in the uploaded report with the observed evidence (screenshot or provider-console observation); a criterion not runnable is marked `(deferred — <reason>)`. - Every FAIL has a filed follow-up Task id in its row. - All test resources created during the run are deleted; the report lists what was created and confirms its deletion in each provider. - No secret appears in the report, screenshots or follow-ups.

Ran the dev oracles on GCP and AWS; Azure deferred because its credential is unfilled. GCP launch and lifecycle work. FAILs: AWS launch never joins (#8877), GCP pages show AWS wording (#8878), Filestore refused (#8879), Windows node vanishes (#8880). Test resources were deleted in the console; provider side is unverified. Memory: none applied.