bazel: ban boost::property_tree::get<ss::sstring> via force-include

[nvartolomei]

boost::property_tree::ptree::get<ss::sstring>(path, default) silently
returns the supplied default for non-empty trees because
seastar::sstring lacks a stream extractor; boost's stream_translator
falls through and the failure is invisible at both compile time and
runtime — the call site looks correct.

This PR makes the pattern a hard compile error.

What's wired

• src/v/base/ptree_ban.h: forward-declares seastar::basic_sstring and
  partially specializes boost::property_tree::translator_between for
  it with a static_assert(false, …) carrying a pointed message.
• //src/v/base:ptree_ban: header-only cc_library (uses the native
  rule directly to avoid the redpanda_cc_library macro recursing into
  itself).
• bazel/internal.bzl: redpanda_copts() appends
  -include base/ptree_ban.h; new redpanda_implicit_deps() returns
  ["//src/v/base:ptree_ban"] so the header is visible under
  layering_check.
• bazel/build.bzl + bazel/test.bzl: thread redpanda_implicit_deps()
  through redpanda_cc_library, redpanda_cc_binary,
  _redpanda_cc_test, _redpanda_cc_fuzz_test,
  redpanda_cc_btest_no_seastar, redpanda_test_cc_library, and
  redpanda_cc_bench.

Third-party cc_library targets are unaffected — only Redpanda's own
macros inject the force-include.

Diagnostic

ptree_ban.h:38:7: error: static assertion failed:
  boost::property_tree::ptree::get<seastar::sstring> silently returns
  the default for non-empty trees because seastar::sstring lacks a
  stream extractor. Use std::string and convert at the call site.
note: in instantiation of … translator_between<std::string,
      seastar::basic_sstring<char, unsigned int, 15>> requested here
src/v/cloud_storage_clients/abs_client.cc:122:26: note: in instantiation
  of … resp.get<ss::sstring>("Error.Code", "Unknown");

Existing breakage surfaced

This change does not compile against dev as-is — it surfaces what
appear to be real, latent silent failures in S3/Azure error parsing
that need follow-up fixes:

• src/v/cloud_storage_clients/abs_client.cc:122-123
• src/v/cloud_storage_clients/s3_client.cc:550-553, 1401-1404, 1837

Those call sites parse cloud error responses and have been resolving
Error.Code / Error.Message / Error.RequestId to the supplied
defaults ("Unknown" / "") regardless of what the server returned.
A follow-up PR will switch them to std::string and adapt the call
sites; this PR is filed as a draft to discuss the approach before that
follow-up lands.

Backports Required

• none - not a bug fix

Release Notes

• none

[nvartolomei]

/rp-unit-test
debug

[nvartolomei]

/ci-repeat 1
debug