Scrub InvalidArgument messages for polyglot callers

## Summary

Follow-up from PR #18024: `CapabilityDispatcher.InvokeAsync` now maps non-type-mismatch `ArgumentException` to `INVALID_ARGUMENT`, but it uses `ex.Message` directly. This bypasses `PolyglotCapabilityErrorFormatter` message scrubbing/alias rewriting, which can expose CLR-oriented member names or .NET-specific guidance to polyglot callers.

## Reference

- PR: https://github.com/microsoft/aspire/pull/18024

## Current behavior

In `src/Aspire.Hosting.RemoteHost/Ats/CapabilityDispatcher.cs`:

- `ArgumentException` (type mismatch path excluded) is converted to:
- `CapabilityException.InvalidArgument(...)`
- message = `ex.Message` (unscrubbed)

This differs from other exception paths that flow through `PolyglotCapabilityErrorFormatter.CreateInternalError(...)` and `ScrubMessage(...)`.

## Why this matters

The current `addParameter` case has a clean message, but future `ArgumentException` messages may include:

- CLR member names instead of polyglot method aliases
- .NET-centric guidance not intended for ATS/polyglot users

That creates inconsistency and can leak implementation details in polyglot error surfaces.

## Proposed follow-up

Keep the `INVALID_ARGUMENT` classification, but normalize/scrub the message before returning it (using the same rewriting/scrubbing logic already used for polyglot-facing error formatting).

## Acceptance criteria

1. `ArgumentException -> INVALID_ARGUMENT` behavior remains unchanged.
2. Returned message is scrubbed/polyglot-friendly (no raw CLR member name leakage where alias mapping exists).
3. Add/update tests in `CapabilityDispatcherTests` to verify scrubbing is applied on this path.