📝 refine async config parser docs

docs/api/async-logger-build-config.md

@@ -40,6 +40,7 @@ Detailed rules explaining key parameters and behaviors
 - Omitting `logger` uses `default_logger_config()`.
 - Omitting `async_config` uses `AsyncLoggerConfig::new()`.
 - The constructor simply packages both config objects into one public build shape.
+- The constructor does not normalize or reinterpret either embedded config beyond those defaults; any normalization has already happened inside the `LoggerConfig` or `AsyncLoggerConfig` values passed in.
 - When passed to `build_async_logger(...)`, the `logger` portion is built first through the normal synchronous config path before the outer async queue layer is applied.
 - When passed to `build_async_text_logger(...)`, the same `logger` portion is consumed more narrowly: `text_formatter`, `min_level`, `target`, and `timestamp` are used directly to build a text console sink, while `LoggerConfig.queue` is not applied.
 - This helper is the main code-side counterpart to `parse_async_logger_build_config_text(...)`.

docs/api/parse-async-logger-build-config-text.md

@@ -38,6 +38,7 @@ Detailed rules explaining key parameters and behaviors
 - `async_config` is parsed through `parse_async_logger_config_text(...)`.
 - If `logger` is omitted, parsing falls back to `default_logger_config()`.
 - If `async_config` is omitted, parsing falls back to `AsyncLoggerConfig::new()`.
+- When either section is present, that nested JSON value is re-stringified and passed through the existing sync or async parser helper rather than being reparsed by a separate schema implementation here.
 - This API separates validation from actual async runtime construction.
 - When the parsed config is later passed to `build_async_logger(...)`, the embedded `logger` section goes through the normal sync builder path first, including optional `LoggerConfig.queue` handling.
 - When the same parsed config is passed to `build_async_text_logger(...)`, only `logger.sink.text_formatter` plus the top-level `min_level`, `target`, and `timestamp` fields are consumed directly, so the sync queue layer is not applied.

docs/api/parse-async-logger-config-text.md

@@ -38,6 +38,7 @@ Detailed rules explaining key parameters and behaviors
 - Parsed values then flow through `AsyncLoggerConfig::new(...)`, so `max_batch` and `linger_ms` receive the same constructor normalization.
 - Overflow parsing accepts both `DropNewest` and the compatibility alias `DropLatest`.
 - Flush parsing accepts both `Never` and the compatibility alias `None`.
+- The error surface here is the general `Failure` path used by the async config utilities, including malformed JSON, non-object roots, wrong field types, and unsupported enum text.
 - Use this API when async policy comes from config text but sink choice is still assembled elsewhere.
 
 ### How to Use