feat: os_log for logging output

[NathanWalker]

os_log landed in Apple SDKs with iOS 10.0, macOS 10.12, tvOS 10.0 and watchOS 3.0 (Xcode 8+).
https://developer.apple.com/documentation/os/generating-log-messages-from-your-code?language=objc

Another good reference:
https://www.donnywals.com/modern-logging-with-the-oslog-framework-in-swift/

This gracefully falls back to NSLog as needed.

Through os_log, we now use standard {public} for console logs per os_log conventions.
This fixes Xcode 26 <private> device log output.

Here’s why os_log is better than NSLog:

1. Performance (huge)

• Deferred formatting: strings aren’t built if the log is disabled, so “off” logs are near-zero cost.
• Binary, lossless storage: logs go to efficient shared buffers instead of synchronous stderr I/O.
• Selective enablement: you can turn on just a subsystem/category at runtime without paying global cost.

2. Privacy & Security

• Field-level redaction: mark values as .private (default in Swift Logger) or .public, so PII won’t leak in production or shared sysdiagnoses.
• Compile-time format safety: avoids format-string injection mistakes common with printf-style APIs.
• Deployment-safe: you can leave logs in release builds without exposing sensitive data.

3. Structure & Control

• Subsystem & category: organize logs (com.yourco.app / network, ui, etc.) so you can filter and toggle precisely.
• Levels with semantics: debug, info, default, error, fault—with different capture/retention behavior on device.

4. First-class tooling

• Console.app & log CLI: query, filter, and correlate across processes and devices.
• Instruments integration: signposts let you time intervals and visualize them alongside CPU, memory, and networking.

5. Future-proof API

• Apple’s modern Swift overlay (Logger in OSLog) keeps improving (better interpolation, stronger typing, richer privacy controls). NSLog isn’t evolving.