refactor: use explicit `&util::TraceThread` function pointer in thread spawns #34736

<!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->

Replace implicit function-to-pointer decay with explicit &util::TraceThread expressions in two thread spawn call sites.

Why: While both forms work the same way, using explicit & is slightly more friendly to the compile, makes the code easy to understand what is happening, and the rest of the project already follows this style for thread spawns. This aligns these two occurrences with that convention. All threads which uses util::TraceThread to spawn now use the explicit & form Verified no remaining inconsistent spawns:

# no remaining inconsistent spawns
$ grep -rn "std::thread(util::TraceThread" src/ | wc -l
0
# all occurrences now use explicit & form
$ grep -rn "util::TraceThread" src/ 

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

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

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Why: While both forms work the same way, using explicit & is slightly more friendly to the compiler as it removes any ambiguity,

Can you explain this? What ambiguity? What is a possible way this can fail here in this context?

and the rest of the project already follows this style for thread spawns.

I think it is fine to fixup the style as part of another pull request in that area/topic. But a stand-alone pull to add or remove redundant & probably isn't needed, when either version is perfectly fine and harmless.

Why:

Can you explain this? What ambiguity? What is a possible way this can fail here in this context?

The ambiguity is for the person who is reading the code, bad writing let me correct it

and the rest of the project already follows this style for thread spawns.

I think it is fine to fixup the style as part of another pull request in that area/topic. But a stand-alone pull to add or remove redundant & probably isn't needed, when either version is perfectly fine and harmless.

Fair, I was studying the concurrency in the project and saw the inconsistency, thought it could be a interesting fix, however as I mentioned it is just stylish change. The pr can be closed if this is not the way to refactoring

Thx, yeah, I think I'll close it for now. If another reviewer sees any value in this, it will be trivial to re-open after a comment.