Emit declared build parameters into build-graph.json

[ChrisonSimtian]

Problem

build-graph.json (the editor-tooling contract in BuildGraphUtility) carries only targets. The build's [Parameter]/[Secret] members — e.g. NuGetApiKey on IPublish, the set dotnet fallout --help lists — never reach the VS Code extension, so it can't surface them.

Outcome

Additive parameters[] in build-graph.json, projected from the build's declared parameters. Schema stays v1 (new field is backward-compatible):

{ "name": "NuGetApiKey", "secret": true, "description": "…", "declaredIn": "IPublish" }

Acceptance criteria

• All declared [Parameter] members are projected, including inherited component params (IPublish, etc.) — matching --help's set.
• [Secret] members flagged secret: true.
• Fields: name, secret, description, declaredIn.
• SchemaVersion unchanged (additive); existing consumers unaffected.
• BuildGraphUtilitySpecs updated to cover the projection.

Context: [ADR-0009] run-config discussion; feeds the extension issue below.

[ChrisonSimtian]

Flagging a downstream consumer, since nothing here mentioned one: Fallout-build/Fallout.Extensions.VSCode#1 is blocked on this and can't start until parameters[] exists.

The VS Code extension's Run Configuration view already collects parameters and secrets — values become --name value args, secrets go to SecretStorage and are passed as environment variables. But it's free-form: you hand-type every name, so a declared member like NuGetApiKey ([Parameter][Secret]) never shows up and the Secrets section reads as empty.

What the extension needs from the graph, to pre-populate rather than guess:

• name — as the CLI expects it
• secret — whether it's [Secret], so it routes to SecretStorage + env var instead of an argument, and renders as "not set" rather than blank
• description / type / default, if cheap — for labels and input hints

Scraping dotnet fallout --help was considered and rejected: it would make the extension a second source of truth for the parameter surface, which drifts the moment the framework changes its output.

Consumer-side detail worth knowing: the extension treats parameters[] as optional and falls back to today's free-form behaviour when absent, so shipping this is not a breaking change for older graphs — no coordination needed beyond the field appearing.