[@miden-sdk/miden-sdk] AppleWebKit: Failed to initialize: Unexpected response MIME type. Expected 'application/wasm'

### Packages versions

@miden-sdk/miden-sdk: 0.15.9

### Bug description

On AppleWebKit browsers (macOS Safari, every mobile browsers on iOS) loading miden_web_client.wasm fails on Next.js/webpack projects with the following error:

> Failed to initialize: Unexpected response MIME type. Expected 'application/wasm'

This bug was probably introduced when working on the capacitor integration?

Claude reported the root cause as:

> It's not a server MIME problem — the WASM is served correctly. It's the SDK picking a worker variant that webpack can't wire up, and it only picks it on WebKit.
>
> WebClient.workerMode defaults to "auto", and _shouldUseClassicWorker() (dist/st/index.js:3377) returns true for any UA with AppleWebKit but no Chrome/ — i.e. exactly Safari. That spawns workers/web-client-methods-worker.js (the classic variant), which inlines the Cargo glue and locates the binary as:
>
> `__wasm_url: new URL("assets/miden_client_web.wasm", self.location.href)`
>
> webpack only rewrites the literal import.meta.url form, so this string survives untouched. At runtime self.location.href is the worker chunk's own URL, so it resolves to /_next/static/chunks/assets/miden_client_web.wasm — which 404s and returns the Next.js HTML error page:
>
> `$ curl -sI https://playground.miden.xyz/_next/static/chunks/assets/miden_client_web.wasm`
> `HTTP/2 404`
> `content-type: text/html; charset=utf-8`
>
> wasm-bindgen's __wbg_load only falls back from instantiateStreaming to arrayBuffer when response.ok is true, so on a 404 it rethrows — and Safari's wording for that rejection is "Unexpected response MIME type. Expected 'application/wasm'", which MidenProvider's errorComponent renders (components/providers/miden-provider.tsx:19).
>
> Chrome takes the module variant, whose WASM goes through a webpack asset module (r.p+"static/media/miden_client_web..wasm" → 200 application/wasm), so it never hits this.

### How can this be reproduced?

Any Next.js/webpack project is affected, confirmed reproduction on the web-client tutorial: https://github.com/0xMiden/tutorials/tree/main/web-client

Hotfix: https://github.com/walnuthq/miden-playground/commit/a9bc6cc80911d71460654df45add7a07225e9baa

### Relevant log output

The issue is in the SDK's worker selection logic for WebKit browsers. Start by examining the `_shouldUseClassicWorker()` function in `dist/st/index.js` around line 3377. Understand how the worker mode 'auto' selects the classic variant. Then look at the worker file `workers/web-client-methods-worker.js` and how it constructs the WASM URL. The fix likely involves ensuring the WASM asset path is correctly resolved in a webpack/Next.js context, possibly by adjusting the URL construction or the worker selection heuristic. Test the fix in a Next.js project like the web-client tutorial.

Written by the indexing model from the issue text.