Makes btck_LogEntry an opaque type with btck_log_entry_get_* accessors, instead of a public struct. This allows adding or changing fields without breaking the ABI, and is consistent with ~all other kernel objects. Follow-up to #34374 (review).
I added a benchmark in https://github.com/bitcoin/bitcoin/compare/master...stickies-v:bitcoin:2026-10/kernel-logentry-bench, and found that performance is not meaningfully impacted either way. Some results below.
<details> <summary>Performance stats</summary>
Performance
Fields are now converted only when read, at the cost of a library call per field. The benchmark measures a kernel log statement up to and including the callback (Apple M4 Pro, static library, -O2, median of 2×25 interleaved runs):
| Callback reads | master | PR | Delta |
|---|---|---|---|
| no fields | 57.4 ns | 55.2 ns | −1.6 to −2.5 ns |
| message only | 57.8 ns | 56.0 ns | −1.4 to −2.0 ns |
| all 9 fields | 57.9 ns | 62.7 ns | +4.8 to +5.4 ns |
Break-even is at 2-3 fields. Either way, the difference is small next to the ~50 ns the log statement costs before the callback, and to what a consumer typically does with the entry (formatting, I/O).
</details>
