Draft: Fix Boost 1.91 build and add missing Python check dependency

This MR addresses two packaging issues found while testing bitcoin 31.0 in a clean chroot:

1. Backport the upstream Bitcoin Core fix for Boost >= 1.91 builds.

   Upstream PR: https://github.com/bitcoin/bitcoin/pull/35175

   Patch: https://github.com/bitcoin/bitcoin/commit/2eafae9dc1bd0f37f42608f2881b81c22fcf3cbc

2. Add python to checkdepends.

   Bitcoin Core v31.0 documents Python 3.10 or newer for scripts and tests: https://github.com/bitcoin/bitcoin/blob/v31.0/doc/dependencies.md

While testing this, another issue showed up after the GCC update: one Bitcoin Core unit test started failing with the current GCC version. I locally tested a small patch for cluster_linearize_tests, and with that patch the failing test passed again with the current toolchain.

I also verified the counter-test with an older GCC version in a clean chroot: without the local test patch, the package still builds and check() passes with GCC 15.2.1. In that run, cluster_linearize_tests passed and the full test suite reported:

  100% tests passed, 0 tests failed out of 157

So this looks like a GCC 16-related test issue rather than a problem already present with GCC 15.

The test patch is not included in this MR. My current assumption is that this should probably be addressed in Bitcoin Core upstream rather than as an Arch packaging patch. I am mentioning it here because it was found while testing this packaging change, and because I would appreciate feedback on whether this is the right assessment before I report it upstream.

Local test patch that makes cluster_linearize_tests pass with the current GCC:

  --- a/src/test/cluster_linearize_tests.cpp
  +++ b/src/test/cluster_linearize_tests.cpp
  @@ -56,7 +56,7 @@

   void TestOptimalLinearization(std::span<const uint8_t> enc, std::initializer_list<DepGraphIndex> optimal_linearization)
   {
  -    DepGraphIndex tx_count = 0;
  +    DepGraphIndex position_range = 0;
       FastRandomContext rng;

       auto test_fn = [&]<typename SetType>() {
  @@ -100,19 +100,22 @@
               SanityCheck(depgraph, lin);
               BOOST_CHECK(std::ranges::equal(lin, optimal_linearization));
           }
  -        tx_count = depgraph.PositionRange();
  +        position_range = depgraph.PositionRange();
       };

  -    // Always run with 64-bit set types
  -    // - The native one that will be used on this platform.
  -    test_fn.template operator()<BitSet<64>>();
  -    // - The one used on 32-bit platforms.
  -    test_fn.template operator()<bitset_detail::MultiIntBitSet<uint32_t, 2>>();
  -    // - An 8-bit one, which is maximally different in terms of bitset behavior.
  -    test_fn.template operator()<bitset_detail::MultiIntBitSet<uint8_t, 8>>();
  +    // Always run with a set type that can hold all encoded test clusters.
  +    test_fn.template operator()<BitSet<256>>();
  +
  +    // Also run with 64-bit set types if the cluster doesn't use indexes above 63.
  +    if (position_range <= 64) {
  +        // - The native one that will be used on this platform.
  +        test_fn.template operator()<BitSet<64>>();
  +        // - The one used on 32-bit platforms.
  +        test_fn.template operator()<bitset_detail::MultiIntBitSet<uint32_t, 2>>();
  +    }

       // Also run with 32-bit set types if the cluster doesn't use indexes above 31.
  -    if (tx_count <= 32) {
  +    if (position_range <= 32) {
           // - The native one that will be used on this platform.
           test_fn.template operator()<BitSet<32>>();
           // - An 8-bit one, which is maximally different in terms of bitset behavior.

I am new to this packaging workflow and I am not a C++ developer. The GCC-related patch was generated with help from an LLM. While I tested that it makes the failing unit test pass with the current GCC, and that the unpatched code still passes with GCC 15, I cannot fully judge whether the change is semantically correct or whether it is the right upstream fix.

Feedback would be appreciated, especially on:

• whether the Boost 1.91 backport and python check dependency are acceptable as-is
• whether the GCC-related test issue should be reported to Bitcoin Core upstream
• whether including the local test patch here for context is helpful or whether it should be omitted from this MR description

Assisted-by: OpenAI Codex (GPT-5.5, reasoning: high)