policy: fix format specifier in SingleTRUCChecks #36225

Motivation & Context

In SingleTRUCChecks (src/policy/truc_policy.cpp:254), the format string:

return std::make_pair(strprintf("tx %u (wtxid=%s) would exceed descendant count limit",
                                parent_entry.GetSharedTx()->GetHash().ToString(),
                                parent_entry.GetSharedTx()->GetWitnessHash().ToString()),
                      consider_sibling_eviction ? (*descendants.begin())->GetSharedTx() : nullptr);

incorrectly specifies %u instead of %s for parent_entry.GetSharedTx()->GetHash().ToString().

While tinyformat falls back to operator<< for std::string and therefore formats the string without crashing at runtime, this is an unintended type specifier mismatch. All other error and debug strings in src/policy/truc_policy.cpp (lines 77, 83, 131, 145, 208, 218) use %s. Furthermore, unit test expectations in src/test/txvalidation_tests.cpp (lines 517 and 556) already expect tx %s (wtxid=%s).

Description of Changes

Replace %u with %s in the strprintf format string in SingleTRUCChecks to maintain type-safety consistency and uniform formatting across truc_policy.cpp.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36225.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Please don't open new pull requests just for tiny typo fixes or refactors, they are a drag on our integration testing infrastructure, maintainer time and reviewer time. See https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#refactoring:

Trivial pull requests or pull requests that refactor the code with no clear benefits may be immediately closed by the maintainers to reduce unnecessary workload on reviewing.

There are many more significant ways to contribute to Bitcoin! Try reviewing open pull requests, reading and testing other contirbutors' code and gaining a broader understanding of the mechanics of the project.