fix(fetch): preserve __sapiom metadata across internal Request cloning

[ygd58]

Fixes #690

sapiomFetch reconstructs the request via new Request(input, init) before reading __sapiom. Native Request cloning does not preserve custom properties, so a __sapiom override set on the original Request was dropped before it could be read - the documented per-request bypass (e.g. request.__sapiom = { enabled: false }) silently had no effect.

Fix: __sapiom is now captured from the original input before cloning and re-attached to the clone, including after the identity-header re-wrap later in the same function (the same class of loss, one function down).

Scope: deliberately limited to the reported reproduction and this identical pattern within sapiomFetch itself. handleAuthorization (interceptors.ts) does its own internal Request re-wrap before returning, which could still drop __sapiom for a caller relying on it past the authorization step (e.g. at payment-retry time) - left as a separate, deeper propagation concern rather than folded into this fix, since it wasn't part of the reported repro.

Tests: added a regression test verifying the enabled:false bypass calls globalThis.fetch directly (skipping authorization) when __sapiom is set on a Request input. Verified it fails against the pre-fix code (hits the unmocked authorization path and throws) and passes against the fix.

Changeset: added (@sapiom/fetch, patch).

Verified locally: pnpm --filter @sapiom/fetch test - 44/44 passing (full package), eslint clean (the one pre-existing warning in fetch.ts is unrelated to this diff).