fix: validate Shamir threshold parameters

[JasonZhouPW]

Summary

• reject Shamir split requests with thresholds below 2
• reject impossible splits where total shares is less than the threshold
• add regression coverage for invalid threshold/total combinations

Why

Before this change, split_secret(0, total, secret) or split_secret(1, total, secret) could create shares that directly expose the secret or cannot be restored by restore_secret. Requests such as threshold > total also appeared to succeed but could not satisfy the requested recovery threshold.

Validation

• RED before fix: focused importlib regression expected ValueError and failed because invalid parameters were accepted
• GREEN after fix: focused importlib regression passes
• valid shamir split/restore cases OK
• PYTHONPYCACHEPREFIX=/private/tmp/pycache python3 -m py_compile pybgl/functions/shamir.py pybgl/test/shamir.py
• git diff --check

Note: python3 -m unittest pybgl.test.shamir -q still fails in this local checkout before loading tests because the native _sha3_hash extension is not built. This is unrelated to this pure-Python Shamir validation change.

Bounty context: submitted for the Bitgesell improvement/PR bounty program (#81 / #39). Preferred payout if approved: USDC/USDT on EVM-compatible rails; details can be provided privately.

[MyTH-zyxeon]

Maintainers - quick review-assist note for pybgl#6 under the Bitgesell improvement/bounty lane (#81).

I only reviewed the public diff; I did not run wallet/node services, use private credentials, or claim payout from this comment. The change is small and useful: rejecting threshold < 2 and total < threshold prevents Shamir shares that either expose the secret or cannot satisfy the requested recovery threshold.

Merge checklist I would want before approval:

• Add the boundary cases threshold=256 and total=256 to the same regression test so the new lower-bound checks do not accidentally narrow coverage around the existing upper-bound guards.
• Consider asserting the error messages, or at least split the parameterized invalid cases into named subtests, so future maintainers can tell which invariant failed without guessing from the tuple.
• Verify the mnemonic wrapper path if it delegates into split_secret; the direct function test is good, but the public API surface may need one wrapper-level invalid-threshold check too.
• Keep the native _sha3_hash build failure separate from this PR. If full unittest cannot run in contributor checkouts, the focused py_compile plus importlib regression evidence in the PR body is reasonable, but maintainers may want one CI-native job that exercises pybgl.test.shamir after extensions are built.
• For #81 payout hygiene, this looks like a small correctness/security hardening PR rather than a broad feature. I would tag it as eligible only after maintainers confirm the bounty process for cross-repo pybgl contributions.

No duplicate implementation PR, live-chain action, secret material, or payment action from me here.