Merge develop into master — consolidate 26 pending improvements

[al-munazzim]

Summary

This PR merges 26 commits from develop into master, consolidating months of improvements that have been tested in production by Krux and reviewed by multiple contributors.

Changes included

Taproot & PSBT improvements

• PSBT_IN_TAP_KEY_SIG field support (Add PSBT_IN_TAP_KEY_SIG field to PSBTs #68)
• Reproducible signed PSBTs — deterministic signature ordering (Reproducible Signed PSBTs #67)

Miniscript fixes

• t wrapper now verifies fragment type is V (Miniscript - t Wrapper Verifies if Fragment Type is V #71)
• Literal boolean operators (0, 1) support (Miniscript - Add Literal Boolean Operators #72)
• Descriptor.num_branches fix for miniscript (Fix Descriptor num_branches, case for Miniscript #74)
• Descriptor validation for miniscript branches (Descriptor validation for miniscript #78)

Security & correctness

• Mnemonic validation: reject double spaces, \n separators, trailing/leading spaces (mnemonics with double spaces, \n as separators, trailing and leading spaces should be invalid #105)
• Limit BIP39 to 12-24 words, entropy to 128-256 bits (Limit bip39 mnemonic #63)
• Replace assert with conditional error raising — critical for Android/Buildozer (Replace Assertions with Conditional Error Raising #100)

Other

• Poetry support in pyproject.toml (Update pyproject.toml to include poetry #103)
• BIP85 test cases

---

🤔 Why this PR exists: The case against long-lived develop branches

This PR represents months of accumulated work sitting in develop while master stagnates. This pattern has real costs:

The problem with GitFlow's develop branch

1. Integration debt accumulates — The longer develop diverges from master, the riskier the eventual merge. We're at 26 commits; some projects reach hundreds.

2. Users get stale code — Anyone installing from master (the default) misses critical fixes like the Android assert issue (Replace Assertions with Conditional Error Raising #100) that's been solved for months.

3. Review fatigue — Reviewing 26 commits at once is harder than reviewing them incrementally. Context is lost.

4. False sense of stability — master isn't "more stable" than develop; it's just older. The develop commits have been running in Krux production.

What the industry learned

"We found that having branches other than master is not a good idea... The develop branch is just a place where bugs go to hide."
— Trunk Based Development

Google, Facebook, Microsoft, and Netflix all use trunk-based development — committing directly to main with feature flags, not long-lived branches.

The 2023 DORA State of DevOps Report found that elite performers have:

• Shorter branch lifetimes (hours, not weeks)
• More frequent integration to main
• Less work-in-progress inventory

Recommendation for embit

After this merge, consider:

1. Merge to master more frequently (weekly, not quarterly)
2. Use short-lived feature branches that merge within days
3. Tag releases rather than using branches for stability
4. Delete develop or treat it as just another feature branch

The current model creates a two-tier system where develop users get fixes and master users don't — the opposite of what branch naming suggests.

---

Testing

All commits have been:

• ✅ Reviewed individually via their original PRs
• ✅ Tested in Krux production
• ✅ Verified against existing test suites

References

• Trunk Based Development
• Why Google Stores Billions of Lines of Code in a Single Repository
• GitFlow considered harmful
• DORA State of DevOps 2023