Expose GetCommandResult for HTTP commands in TypeScript and other polyglot AppHosts

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

C# `WithHttpCommand` supports `HttpCommandOptions.GetCommandResult`, allowing an AppHost to inspect an HTTP response and return a custom `ExecuteCommandResult`. TypeScript and other polyglot AppHosts do not have the equivalent callback: `HttpCommandExportOptions` exposes `PrepareRequest` and `ResultMode`, but not `GetCommandResult`.

A motivating scenario is invoking an API that returns JSON, then formatting selected response fields into a Markdown report displayed immediately in the dashboard. The formatting belongs in the AppHost command; the API should not need to return presentation-specific Markdown.

Regular custom commands can return Markdown result data, but polyglot HTTP commands cannot transform the response into that result. `ResultMode` only supports `None`, `Auto`, `Json`, and `Text`. Adding a Markdown mode alone would not solve JSON-to-Markdown transformation.

### Describe the solution you'd like

Expose a `getCommandResult` callback for TypeScript and equivalent callbacks for other polyglot AppHosts, returning the existing `ExecuteCommandResult` type used by custom commands.

Suggested approach:

- Provide a language-neutral response representation with status code, success status, headers, and response body as a string, rather than exposing .NET's `HttpResponseMessage`.
- Include relevant invocation context, consistent with existing HTTP-command callbacks.
- Adapt the exported callback into the existing C# `HttpCommandOptions.GetCommandResult` hook, following the existing `PrepareRequest` adapter pattern.
- Preserve C# semantics: invoke the callback for both successful and unsuccessful HTTP responses; a supplied callback takes precedence over `ResultMode`. Preserve current behavior when no callback is supplied.
- Surface callback and JSON-parsing errors as command failures rather than silently falling back to default response handling.

Illustrative TypeScript usage below is a proposed API shape, not an existing API:

```ts
api.withHttpCommand("/report", "Show report", {
getCommandResult: async ({ response }) => {
if (!response.isSuccessStatusCode) {
return {
success: false,
message: `Request failed: ${response.statusCode}`,
};
}

const report = JSON.parse(response.body);

return {
success: true,
message: "Report ready",
data: {
value: `# ${report.name}\n\n**Status:** ${report.status}\n**Items processed:** ${report.itemCount}`,
format: "Markdown",
displayImmediately: true,
},
};
},
});
```

No generic JSON-to-Markdown converter is necessary: callers can parse the response and format meaningful output using their language's standard facilities.

Coverage should include callback export/code generation, successful JSON-to-Markdown transformation with immediate display, non-2xx response handling, callback failures, and unchanged default behavior when no callback is configured.

### Additional context

Relevant implementation:

- `src/Aspire.Hosting/ApplicationModel/HttpCommandOptions.cs`: C# `GetCommandResult` and the polyglot `HttpCommandExportOptions` surface.
- `src/Aspire.Hosting/ApplicationModel/HttpCommandContext.cs`: existing C# response context and polyglot prepare-request context.
- `src/Aspire.Hosting/ResourceBuilderExtensions.cs`: `CreateHttpCommandOptions` adapter and HTTP command execution.

Related closed issues: #8729 and #10748 introduced/discussed command-result display, but do not cover this remaining polyglot callback gap.

Recognizing `text/markdown` in `ResultMode.Auto` or adding an explicit Markdown result mode would be a separate convenience; neither replaces the response-transformation callback.

Start with src/Aspire.Hosting/ApplicationModel/HttpCommandOptions.cs and HttpCommandContext.cs, then trace the adapter and execution flow in src/Aspire.Hosting/ResourceBuilderExtensions.cs, especially the existing PrepareRequest pattern. Run the relevant HTTP-command tests and cover export/code generation, JSON-to-Markdown output, non-2xx responses, callback failures, and unchanged behavior without a callback.

Written by the indexing model from the issue text.