feat(logging): add logging macros (4/6)

[kamcheungting-db]

Part 4 of the logging stack (builds on #724). Adds the application-facing macros — the part most callers actually use.

What's here

• ICEBERG_LOG_{TRACE,DEBUG,INFO,WARN,ERROR,CRITICAL,FATAL}, the generic ICEBERG_LOG(level, …), ICEBERG_LOG_TO(logger, …), and ICEBERG_LOG_RUNTIME_FMT for runtime format strings.
• ICEBERG_LOG_ACTIVE_LEVEL is a compile-time floor: statements below it are removed entirely. ICEBERG_LOG_FATAL always emits, flushes, then aborts.
• Filtering is decided only by ShouldLog(); formatting happens only on the taken path and never throws (a bad format falls back safely).
• Generic/runtime-format macros use the same lock-free fast path as the fixed-severity ones (the slot lock is taken only on the fatal/abort path).
• Bare LOG_* aliases are opt-in via ICEBERG_LOG_SHORT_MACROS.

Build note — sets /Zc:preprocessor on MSVC, required for the __VA_OPT__ used by the macros.

Examples — every macro takes a std::format string + args. The rendered line depends on the active backend; with the default CerrLogger it looks like:

ICEBERG_LOG_TRACE("entering scan for {}", table);
  2026-06-16T10:59:41.186Z trace [12345] table_scan.cc:88] entering scan for db.t
ICEBERG_LOG_DEBUG("cache miss key={}", key);
  2026-06-16T10:59:41.186Z debug [12345] cache.cc:42] cache miss key=manifest-7
ICEBERG_LOG_INFO("loaded {} manifests in {} ms", n, ms);
  2026-06-16T10:59:41.186Z info [12345] table_scan.cc:91] loaded 5 manifests in 12 ms
ICEBERG_LOG_WARN("retry {} after {}", attempt, err);
  2026-06-16T10:59:41.186Z warn [12345] io.cc:51] retry 2 after timeout
ICEBERG_LOG_ERROR("commit failed: {}", status);
  2026-06-16T10:59:41.186Z error [12345] txn.cc:77] commit failed: conflict
ICEBERG_LOG_CRITICAL("metadata unreadable at {}", path);
  2026-06-16T10:59:41.186Z critical [12345] meta.cc:30] metadata unreadable at s3://b/m.json
ICEBERG_LOG_FATAL("unrecoverable: {}", reason);   // emits, flushes, then std::abort()
  2026-06-16T10:59:41.186Z fatal [12345] boot.cc:19] unrecoverable: bad config

Less common forms: ICEBERG_LOG(level, …) (runtime severity), ICEBERG_LOG_TO(logger, level, …) (explicit logger), ICEBERG_LOG_RUNTIME_FMT(level, fmt_string, args…) (non-literal format). The same examples are documented inline in logger.h.

Tests — macros_test / macros_active_level_test: formatting, level gating, "argument not evaluated when disabled", compile-time stripping, never-throws, and FATAL-aborts death tests. clang/libc++.

This pull request and its description were written by Isaac.

[wgtmac]

This should use the current scoped logger rather than the process default. ScopedLogger says LOG_* routes through the scoped binding, but this path would send a fatal record to the global default and then abort.

[wgtmac]

Great work on the logging macros! I have a few suggestions regarding performance, binary size, and exception handling for your consideration.

[wgtmac]

Performance/Heap Allocation: std::format returns a std::string. If the formatted message exceeds the Small String Optimization (SSO) limit, this will trigger a heap allocation before the logger even processes it. For a high-performance system like Iceberg, this could become a bottleneck on hot paths. Consider using a stack/thread-local buffer (like fmt::memory_buffer in fmtlib or spdlog) to achieve zero-allocation formatting.

[wgtmac]

Binary Bloat: Expanding this entire block (including if, try-catch, and ShouldLog) at every log call site can significantly bloat the binary size and reduce instruction cache hit rates. A common optimization is to use type erasure (e.g., std::make_format_args) and push the actual try-catch execution into a non-inline function in the .cc file.

[wgtmac]

Exception Handling Scope: catch (...) is very broad and will swallow all exceptions, including std::bad_alloc (OOM) or thread cancellation exceptions (e.g., POSIX abi::__forced_unwind). Since std::format typically throws std::format_error, it is safer to catch const std::format_error& or const std::exception& so fatal system exceptions can propagate.

[wgtmac]

Extensibility: Hardcoding std::abort() removes the ability for the host application (like a Java JNI or Python process embedding Iceberg) to handle fatal errors gracefully (e.g., flushing resources or printing a stack trace). Consider allowing the user to register a custom FatalHandler callback before falling back to abort().