fix(provider): fail with ProviderError for Kupo plutus:v4 scripts and Byron addresses

[Kshot3000]

Fixes #572.

Kupo (checked against v2.10.0 to v2.12.0 in the issue) can return two responses the Kupmios provider could not handle. Both now fail as typed ProviderErrors — the error type every other Kupmios read path already returns — instead of an opaque parse error or an unhandled defect.

PlutusV4 scripts

• ScriptSchema in Kupo.ts now accepts the plutus:v4 literal that /scripts/{hash} can return since Kupo v2.12, so the response decodes.
• getScriptEffect matches on the language with Effect.flatMap instead of Effect.map. The languages the SDK models (native, PlutusV1/V2/V3) resolve as before; anything else — today that is plutus:v4 — fails with a ProviderError naming the language as not supported yet. Before, the schema rejection surfaced as a generic parse error buried in the cause chain (after five retries of a deterministic failure), and the default: throw in the old Effect.map would have turned the newly accepted literal into a defect.

Byron addresses

• Kupo writes Byron-era addresses in base58 (src/Kupo/Data/Cardano/Address.hs in Kupo). kupmiosUtxosToUtxos decoded every returned address with CoreAddress.fromBech32 inside Effect.map, so a Byron output from an output-reference or policy query threw and surfaced as a defect (Cause.Die — I reproduced exactly that). The decode now runs through Effect.try and fails with a ProviderError that names the address and explains that Kupo writes Byron addresses in base58 and that Byron addresses are not supported, since a UTxO's address here is a Shelley Address and cannot represent one.

Tests — four new cases in test/provider/Kupmios.test.ts, all with fetch stubbed in the file's existing style:

• a /matches UTxO carrying a Byron base58 address (the output address from Kupo's golden vector test/vectors/golden/1.json) fails with Cause.Fail + ProviderError mentioning Byron/base58 — red before this change as Cause.Die;
• ScriptSchema decodes {language: "plutus:v4"} — red before as a ParseError;
• a plutus:v4 reference script fails with a ProviderError whose cause chain names plutus:v4 as not supported and contains no parse error — red before;
• a plutus:v3 reference script still resolves to a PlutusV3 script reference (happy-path guard for the map → flatMap restructure).

Full package suite: 2,736 passed, 7 skipped, 0 failed. tsc --noEmit and eslint clean; a patch changeset is included.

I am an independent builder, not affiliated with Intersect, the Cardano Foundation, or IOG.

---

@Kshot9000 (https://x.com/kshot9000) · ADA: addr1q8hnl6vl5a6k3rw3n5g3jtte696zcl76kfatzv7gpswa9r0dj7fma6klq55y4ffm7tf0em09udnyhuk4ah92pl5x9jpqjae44v

[Kshot3000]

Correction to the test totals in my commit message and the PR description above: the "2,736 passed, 7 skipped" figure was wrong — it came from a background test result on this machine that was not this package's suite, and I quoted it before this run's own result landed. My mistake.

The actual full-suite result for @evolution-sdk/evolution on this branch (exit code 0):

• Test Files: 101 passed | 1 skipped (102)
• Tests: 1,682 passed | 75 skipped (1,757), 0 failed
• test/provider/Kupmios.test.ts on its own: 20/20 passed (16 existing + the 4 new cases)
• tsc --noEmit and eslint clean, as stated

The conclusion is unchanged — the whole suite is green — only the totals were misstated.