Build/Deployment/Run Configuration views + Explorer dock

[ChrisonSimtian]

Draft. Restructures the extension's single Targets view into several collapsible Views, mirrors the build targets into the file Explorer, and adds a Run Configuration form.

What's in it

• Build view — the target tree, registered in both the ☢️ Fallout container (fallout.build) and the file Explorer (fallout.buildExplorer); one TreeDataProvider, two homes.
• Deployment view — placeholder; lights up once the framework emits a deployment-graph.json for the ADR-0009 CD flow.
• Run Configuration — a webview-view form: parameters (workspaceState → --name value args) and secrets (SecretStorage → env vars; values never rendered).
• Run flow — ▶ applies the saved config silently; Run with Parameters… prompts an InputBox prefilled with the target + saved args.

Scope / relation to #1

Relates to #1. This delivers the Run Configuration view (the vessel); #1's real ask — declaration-driven population (e.g. NuGetApiKey appearing automatically from the build's [Parameter]/[Secret] members) — is not in this PR and stays open. It's blocked on Fallout-build/Fallout#499 (the graph must emit parameters[] first). So this PR does not close #1.

Verify

• npm run compile clean; new src/runConfig.ts.
• Load via Extension Development Host against a repo with .fallout/temp/build-graph.json.

[ChrisonSimtian]

Closing and reopening to make CI run. This branch predates the PR gate, so no check ever ran on it, and retargeting to develop fires only pull_request: edited — which isn't in the default trigger set (opened, synchronize, reopened). Reopening is the least invasive fix: it triggers the gate without adding a commit to your branch.

[ChrisonSimtian]

Decomposed into one issue per feature for the First full release milestone, so each can land as its own PR and produce its own release-note line:

• Restructure the Fallout container into Build, Deployment and Run Configuration views #9 — Restructure the container into Build / Deployment / Run Configuration views (breaking-change)
• Mirror the Build view into the file Explorer #10 — Mirror the Build view into the Explorer
• Deployment view #11 — Deployment view (decision needed: ship the placeholder or strip it)
• Run Configuration view: build parameters as CLI arguments #12 — Run Configuration: parameters as CLI args
• Run Configuration view: secrets via SecretStorage, passed as environment variables #13 — Run Configuration: secrets via SecretStorage → env vars (security)
• Apply the run configuration on run, and add a "Run Target with Parameters…" command #14 — Apply the run config on run, plus "Run Target with Parameters…"

This PR carries all six. Leaving it open and rebased — whether it merges as-is or gets split into six PRs is the housekeeping call for later. Splitting buys six release-note lines instead of one; merging as-is buys not doing the work.

Existing #1 (populate params/secrets from the build's declarations) is deliberately not in the milestone: it's blocked on Fallout#499, which is still open, and the current build-graph.json has no parameters[]. Putting it in would make the milestone hostage to another repo.

[ChrisonSimtian]

Superseded by a per-feature split, so each feature lands as its own release-note line:

PR	Issue	Feature
#15	#9	Rename the Targets view to Build (breaking)
#16	#10	Explorer dock
#17	#11	Deployment view
#18	#12	Run Configuration — parameters
#19	#13	Run Configuration — secrets
#20	#14	Apply the run configuration on run

Stacked in that order, each based on the previous. Verified the six increments reconstruct this branch's tree byte-for-byte, and each one compiles on its own.

Leaving this open until the stack merges, as the umbrella.