Kernel (libbitcoinkernel): ranking notes

The category splits cleanly: a P2 tier of project-defining work (build-level kernel separation, error propagation at the boundary, storage/validation capabilities external consumers ask for, and the logging API decision), a P3 tier of genuine but deferrable API completeness and boundary cleanups, and a P4 tier of cosmetic or mechanical items. Four PRs (#35948, #35861, #35642, #24230) have most of their substance outside kernel; they are banded here only on their kernel-boundary effect.

• Logging API direction is contested across four PRs: #34775 (single global callback) versus #30342 and #33847 (per-instance/contextual loggers, both parked in draft, #30342 carrying an approach NACK). #34775 should be reviewed first because it settles the direction and is the stated prerequisite for #34374; #30342/#33847 only make sense if the contextual direction wins.
• Chain order: #34775 -> #34374. Reviewing #34374 before the logging-handle question in #34775 is settled risks redoing the structured-entry API.
• #35322 rewrites Logger internals (atomic bitmasks, dropped methods) and touches the kernel C API adaptation; its own card says it will be superseded by the larger kernel logging rework, so it should be sequenced against #34775/#34374 rather than reviewed in isolation.
• #29700 and #35646 attack the same problem - runtime/fatal errors conflated with BlockValidationState. #29700 is the broader, more mature treatment (structured error return for kernel embedders) and should be reviewed first; #35646 should then be re-scoped to what remains rather than reviewed in parallel.
• #29700 is stacked on open #25665; #35861 is stacked on unmerged #35793 - in both cases the parent governs review order.
• #35557 has an unanswered question from maflcko about whether it is still needed after #35496 merged; if the answer is no, it drops out of the list entirely.
• #35948 and #35861 are only marginally in this category (comment/unit fixes and a chain-type constant respectively); their real weight, if any, lies in init and consensus/chainparams categories.

• #33117: P4 alone, P3 after comparison. Raised to P4->P3: it extends the kernel notification boundary with snapshot progress and unblocks downstream GUI work, which is more than the cosmetic/mechanical items left in P4.

This pass by claude-opus-5 on 2026-09-17 saw every PR in the category at once and checked the bands given to each PR alone against each other, ordered the PRs, and noted chains and overlaps. Back to the category.