Fix AppHost startup args and expose client setup path

[niemyjski]

Summary

• Preserve and harden Aspire launch in Codex environment for local startup by writing ASPIRE_HOME, cleaning generated logs in cleanup, and passing CLI flags to skip trust and allow unsecured transport.
• Make AppHost honor launch flags (--skip-trust-developer-certificate, --allow-unsecured-transport, --disable-dashboard) through DistributedApplicationOptions.
• Reduce onboarding friction by adding an in-app Client Setup path from project navigation and API Keys table.
• Add quick-copy Server URL and API key values to Configure page for faster client wiring.

Testing

• No local test run completed in this pass; runtime restore still depends on environment network/DNS availability for package feeds.
• Changes are isolated to startup configuration and UI navigation/markup; runtime behavior should be validated with local aspire run once package restore can complete.

Notes

• Branch intentionally excludes local .aspire-home artifacts; only source changes are included.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f32a87734a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Pass AppHost args into the builder options

With this new DistributedApplicationOptions object, the Aspire builder no longer receives the original command line; the official CreateBuilder(options) docs call out setting Args = args so deployment tools can put the AppHost into publish mode. Any aspire publish/manifest-generation invocation that relies on those AppHost arguments will be ignored and run with default builder behavior instead, so add Args = args while keeping the new flag-derived options.

Useful? React with 👍 / 👎.

[niemyjski]

@ejsmith quick product naming check: this PR exposes the existing /project/{projectId}/configure route more directly, but we currently have mixed labels for the same concept:

• New project settings route / command palette entry: Client Setup
• Project layout heading for the configure route: Send Events
• Existing project-list action: Download & Configure Client (this matches the old Angular wording)

Should we standardize this route as Download & Configure Client for old-site continuity, or is Client Setup the better new-site label since the page is really package install + API key/server URL + sample event setup? I lean toward one canonical label everywhere rather than adding another synonym, but wanted your call before I change the copy across the route, heading, manage button, API keys shortcut, and project action.

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
Exceptionless.AppHost	39%	40%	132	❌
Exceptionless.Core	72%	64%	8644	➖
Exceptionless.Insulation	24%	23%	205	❌
Exceptionless.Web	79%	67%	5231	✔
Summary	72% (17185 / 23730)	64% (8760 / 13672)	14212	➖