docs: fix inaccurate Customize Azure resources page

[IEvangelist]

Fixes #246

Problem

The page at https://aspire.dev/integrations/cloud/azure/customize-resources/ contains three concrete API inaccuracies that mislead readers building custom Bicep workflows. Verified each claim against the microsoft/aspire main source tree and against the live page on aspire.dev (screenshot in Evidence below).

Changes

All edits are scoped to src/frontend/src/content/docs/integrations/cloud/azure/customize-resources.mdx plus one allowlist entry pair in src/frontend/tests/unit/twoslash-blocks-audit.ts (see Twoslash note below).

• AddBicepTemplate instead of AddAzureBicepResource in the C# Use custom Bicep files sample. AddAzureBicepResource is not a public API; the real APIs are AddBicepTemplate(name, bicepFile) and AddBicepTemplateString(name, bicepContent). The TypeScript sample was already using the correct addBicepTemplate name.
• Replaced .WithReference(storage) on the bicep resource with .WithEnvironment("STORAGE_CONNECTION_STRING", storage.GetOutput("connectionString")). AzureBicepResource does not implement IResourceWithConnectionString, so the original snippet did not compile. Showing GetOutput here also addresses one of the reporter's wishlist items (consuming outputs from a custom Bicep template).
• Rewrote Inspect generated Bicep. Running the AppHost locally (aspire run) does not write Bicep into the project — local provisioning compiles Bicep into a temporary aspire-bicep directory (per BicepProvisioner.cs). Updated the steps to use aspire publish (or aspire deploy) and to look in the aspire-output folder (the publish/deploy default per PublishCommandStrings.resx). Added a note callout calling out the difference and a tip callout pointing to the Azure Portal Export template trick.
• Replaced the hallucinated SubnetReference example in Add Azure resources to the infrastructure with the idiomatic Aspire pattern using AzurePrivateEndpointExtensions.AddPrivateEndpoint (from Aspire.Hosting.Azure.Network). Added a TypeScript note that the high-level builders are C#-only today, plus a fallback paragraph pointing readers at ConfigureInfrastructure + Azure.Provisioning for advanced needs not covered by Aspire-native builders.
• New Pass parameters and read outputs subsection under Custom Bicep templates with C# and TypeScript samples for AddParameter(name, secret: true), WithParameter(name, parameterResource), and GetOutput(name). Added a bulleted list of the supported WithParameter value types (ParameterResource, BicepOutputReference, ReferenceExpression, IResourceWithConnectionString, EndpointReference) and a LearnMore link to the playground/bicep sample for end-to-end scenarios — closes the wishlist items in the issue.
• Added a tip about AddBicepTemplateString / addBicepTemplateString for inline Bicep snippets.
• See also: added the playground/bicep sample link.

Evidence

Live aspire.dev page before the fix (issue still reproduces today):

• Section Use custom Bicep files shows builder.AddAzureBicepResource(name: ..., bicepFilePath: ...) followed by .WithReference(storage).
• Section Inspect generated Bicep lists three steps starting with "Run your AppHost locally" and pointing readers at ./infra.
• Section Add Azure resources to the infrastructure shows new PrivateEndpoint("storagepe") { Subnet = new SubnetReference { Id = "..." } }.

Local rendered HTML after the fix shows the new AddPrivateEndpoint(blobs) snippet, the rewritten aspire publish / aspire-output steps, and the new Pass parameters and read outputs subsection in the right-hand TOC.

How I verified

1. Fast-forwarded microsoft/aspire.dev:main and microsoft/aspire:main, then created dapine/fix-customize-azure-resources-246 from the new tip.
2. For each claim in the issue, located the implementing C# file in microsoft/aspire and the matching polyglot TypeScript usage in tests/PolyglotAppHosts/ to confirm the real API surface (signatures and call patterns).
3. Loaded https://aspire.dev/integrations/cloud/azure/customize-resources/ via Playwright and confirmed all three inaccuracies are still present today.
4. Edited customize-resources.mdx, then ran:
   • pnpm --dir src/frontend exec astro sync — clean (no errors related to this page).
   • pnpm --dir src/frontend exec astro build — page builds and renders in all 12 locales (errors in the build log are pre-existing GitHub API rate limits in getContributors.ts and unrelated TypeScript reference page collisions).
   • pnpm --dir src/frontend twoslash-types then pnpm --dir src/frontend test:unit:twoslash-blocks — passes after the allowlist entries below.
5. Spot-checked the rendered dist/integrations/cloud/azure/customize-resources/index.html to confirm the new section headings appear in the on-this-page TOC and the new code samples are present.

Twoslash note

The two new TypeScript twoslash blocks call withParameter(name, { value }) with a string and a ParameterResource. The polyglot test tests/PolyglotAppHosts/Aspire.Hosting.Azure/TypeScript/apphost.ts uses this exact pattern, so the runtime API supports it. However, the current aspire.d.ts generator only emits the last withParameter overload ({ value?: EndpointReference }), so twoslash reports ts(2769) — No overload matches this call. Added two KNOWN_TYPE_BUGS entries with a clear label so the regression gate stays precise; the entries fall out automatically once the generator emits all overloads (separate, pre-existing concern in scripts/generate-twoslash-types.ts).

Out of scope

• The deeper type-shape gap in the twoslash type generator — only the last overload of withParameter is emitted to aspire.d.ts. Worth a follow-up issue against scripts/generate-twoslash-types.ts, but outside the scope of this docs fix.