addAlert() receives an Error object behind @ts-expect-error in two audio paths

## Summary Two audio error paths pass a caught `unknown`/`Error` straight to `useToastStore().addAlert()`, which takes a `string`, and silence the resulting type error with `@ts-expect-error`: - `src/extensions/core/uploadAudio.ts` — in the `uploadFile` catch - `src/services/audioService.ts:68` ```ts // @ts-expect-error fixme ts strict error useToastStore().addAlert(error) ``` `src/AGENTS.md` says "Avoid `@ts-expect-error` — fix the underlying issue", and every other `addAlert` call site in the repo passes a string. ## Why it needs its own change The obvious fix changes observable behaviour — the alert payload goes from the `Error` object to `error.message`. An existing test pins the current behaviour: ``` uploadAudio.test.ts > rolls back the widget value and clears isUploading when upload throws synchronously - Error { "message": "Upload failed before request promise" } + "Upload failed before request promise" ``` So this needs the test updated deliberately, and both call sites done together, rather than being folded into an unrelated PR. Raised by CodeRabbit on https://github.com/Comfy-Org/ComfyUI_frontend/pull/15114 and deferred there for exactly this reason. ## Suggested fix ```ts useToastStore().addAlert(error instanceof Error ? error.message : String(error)) ``` applied at both call sites, with the pinning assertion in `uploadAudio.test.ts` updated to the message string. Worth checking what the toast actually rendered for an `Error` object before the change — if it stringified to `[object Object]`, this is a user-visible bug fix rather than a pure type cleanup.