feat: support Cardano across both address eras

[aeitwoen]

Adds cardano to the registry: coin type 1815, cip34:1-764824073 for CAIP-2, cardanoscan as the explorer, and a validator that takes all three shapes an ADA address actually comes in - Shelley addr1, stake stake1, and Byron base58. Every accepted vector in the tests is lifted straight from CIP-19, bounds included: the bech32 data part runs 53 to 98 characters because Cardano waives BIP-173's 90-char cap, so the limits come from the payload sizes instead. Key is the full name, not the ticker - that's the side #8 picked.

The fun part is Byron. No CBOR parser needed - the envelope is rigid enough that four fixed bytes plus the length byte tying to the total settles it, and that's what keeps Solana keys and Base58Check addresses out. One honest gap: a Byron testnet address still passes, its network hides in an attribute a format check won't open. Shelley testnet prefixes are rejected the way Bitcoin's testnet versions are.

[cubic-dev-ai]

All reported issues were addressed across 9 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

2 issues found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/chains/cardano.ts">

<violation number="1" location="src/chains/cardano.ts:26">
P2: When the Byron payload is truncated, `isByronEnvelope` accepts an inner `0x83` header without any of its three items. `Cardano.assertAddress("5xb5UCMiej")` therefore accepts a malformed Base58 value; require the minimum complete payload and validate the inner items before classifying it as Byron.</violation>
</file>

<file name="test/unit/chains.test.ts">

<violation number="1" location="test/unit/chains.test.ts:469">
P3: The new JSDoc says one of the two added vectors tests a CRC width CBOR cannot encode, but neither vector reaches the CRC-width branch. Both decode to envelopes whose byte 5 is not 0x83 (0xaa and 0x00), so isByronEnvelope returns false at the array(3) opening check and the head/crcBytes branch is never exercised. Make the comment reflect that both vectors are rejected at the payload-array check, or craft an envelope with decoded[5]===0x83 and an invalid CRC width so the claimed branch is actually covered.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>