feat(logger): add new logging apis - #759

Preserve formatting for missing fields with format specs

When an omitted placeholder has a conversion or format specifier, such as logger.info("{user} owes {amount:.2f}", user="alice"), __missing__ supplies the string "{amount}", formatting that string as a float raises, and this broad fallback restores the entire original template. Consequently even supplied parameters are left uninterpolated, contrary to the documented behavior that only missing parameters remain as placeholders. Preserve the missing field's conversion/specifier instead of abandoning all rendering.

Useful? React with 👍 / 👎.

Normalize supported metadata before adding template attributes

When a caller combines template parameters with Pydantic-style metadata accepted by the rest of the logger API, this direct conversion can raise TypeError: an object implementing the supported model_dump() or dict() protocol is not necessarily iterable. The same metadata works when no template parameters are supplied because the normal event sanitizer handles those protocols, so logger.info("User {id}", metadata=model, id=...) unexpectedly emits no log. Retain the Metadata input contract and normalize it before merging the template attributes.

Useful? React with 👍 / 👎.

Preserve level as a template parameter in helpers

When a severity helper is given a template parameter named level, such as logger.info("Connected at {level}", level="database"), the helper collects it in parameters and then passes it alongside the fixed level="info" argument, causing Python to raise TypeError: got multiple values for keyword argument 'level' before any log is emitted. Since named placeholders are otherwise advertised without restrictions, pass template parameters through a non-colliding container or render them before forwarding.

Useful? React with 👍 / 👎.

Preserve mapping keys in logging template metadata

When standard logging interpolation uses a non-dict mapping such as collections.UserDict (logger.info("%(user)s", UserDict(user="alice"))), LogRecord stores that mapping directly in record.args and formats the message successfully. This branch instead treats it as positional arguments and enumerates its keys, recording braintrust.template.parameter.0 = "user" rather than braintrust.template.parameter.user = "alice", so the emitted template attributes are silently incorrect; recognize general Mapping instances here.

Useful? React with 👍 / 👎.

AI reviewer flagged a potential deadlock:

logging.shutdown() (registered at exit) acquires each handler's RLock and holds it across h.flush(). BraintrustLogHandler.flush() delegates to Logger.flush(), which submits batches to HTTP_REQUEST_THREAD_POOL and blocks on concurrent.futures.wait (logger.py:1270, 1279). Those pool threads run requests/urllib3, which emit their own log records; each one enters Handler.handle(), hits with self.lock, and parks because a different thread holds the RLock. The future never resolves, wait() never returns, the lock is never released. The "urllib3" entry in _IGNORED_LOGGER_PREFIXES doesn't help — it's checked at the top of emit() (logs.py:71), which is already inside the lock.