SFT-7491: keep authorization credentials out of the log

[georgesFoundation]

send() wrote the whole serialized transmit buffer to the log at debug level, so mining.authorize put the pool user and password into ordinary diagnostic output (CWE-532). mining.submit repeats the user in every share, and pools echo it back at us: Public-Pool answers a failed authorization with [20, "...", ", "].

Every frame the client logs now goes through Sensitivity::loggable, and it is that return value, never a buffer, that reaches a logging macro. The decision is made before the macro is invoked, so it holds for both backends fmt maps onto and at every level. send() takes the classification as a required argument rather than inferring it, so a new secret-bearing request cannot be added without someone choosing one.

Classified secret: mining.authorize and mining.submit, plus any response matched to a pending one of those. Everything else is logged in full and documented in the crate docs as carrying no authorization parameter.

Raw receive-buffer dumps are gone. A buffer, and a freshly read chunk, span an arbitrary number of frames, so at that point there is no way to tell whether one of them echoes a credential; the per-frame log covers the useful case and can be classified. The commented-out transmit-buffer dump is removed too rather than left as an invitation.

Error::Pool is the one credential-adjacent value handed back rather than logged, since its message and detail are pool-chosen text that can echo the user. Documented on the variant.

The regression test drives a full handshake with canary credentials and a capturing logger at trace level, and asserts neither canary nor any fragment appears. It caught the read-path chunk dump that reading the send path alone would have missed. defmt cannot be captured in a host test, so it is covered by construction plus unit tests pinning loggable. Adds a flake check so the log-gated test actually runs; the all-features checks have to exclude this crate.

[badicsalex]

The code changes are sane (although more complicated than warranted IMO), the tests are mostly unnecessary.

Compare to the similar patch in keyos, and the upcoming policy that allows these data in trace! but makes sure trace is never used in production.