Bytewords SSKR shares with legacy CBOR tag 309 (crypto-sskr) are rejected; only 40309 is accepted #12

Summary

seedtool --in sskr rejects standard Bytewords SSKR shares that use the legacy CBOR tag 309 (SSKR_SHARE_V1, crypto-sskr), even though it accepts that legacy tag for URs. The only message is Error: Insufficient or invalid SSKR shares., which hides the real cause.

This breaks interoperability with sskr-tool 0.1.2 (see ksmithbaylor/sskr-tool#1), which still reads and writes tag 309.

Version

seedtool-cli 0.4.0 (commit 9888d7d), bc-tags 0.12.0, bc-components 0.31.1, dcbor 0.25.2.

Steps to reproduce (synthetic data only)

1. Generate 2-of-3 shares with sskr-tool split 2of3 1 (Bytewords, tag 309), or take the test vector from BCR-2020-011 and encode it with tag 309 (header d9 0135 55).
2. Put two of the shares in a file, one per line, and run seedtool --in sskr --out hex < shares.txt.

Actual result

Error: Insufficient or invalid SSKR shares. for all three pairs of shares.

Expected result

The shares are recovered, as they already are for ur:crypto-sskr shares (parse_ur(input, tags::TAG_SSKR_SHARE_V1, true)).

Analysis

• In src/formats/sskr.rs, from_tagged_cbor_shares (the Bytewords path) calls try_into_expected_tagged_value(tags::TAG_SSKR_SHARE), which is tag 40309. There is no fallback to TAG_SSKR_SHARE_V1 (309) on this path.
• BCR-2020-011 says version 2 sskr "differs from version 1 crypto-sskr only in the CBOR tag and UR type" and that version 1 "may still be supported for backwards compatibility".
• I changed only the tag bytes of the shares and recomputed the Bytewords CRC. After that, seedtool recovers shares generated by sskr-tool for 2-of-3, 3-of-5 and two-group configurations. In the other direction, sskr-tool recovers seedtool shares once their tag is rewritten to 309. So the secret sharing, metadata and Bytewords layers are compatible. The tag is the only difference.
• The BCR-2020-011 test vector is recovered by seedtool with tag 40309 and rejected with tag 309.
• parse_bytewords uses filter_map(... .ok()) on the decoded lines. A line that fails to decode is silently dropped, so all failure causes end in the same generic message.

Suggested changes

1. In the Bytewords input path, also accept tag 309, as is already done for URs.
2. Add a test that recovers the BCR-2020-011 vector from Bytewords shares encoded with tag 309.
3. Optionally, report which line failed (invalid word, bad CRC, wrong tag) instead of the generic message.

Output should stay on tag 40309.