📝 clarify async build export sink-kind semantics

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

@@ -42,6 +42,7 @@ Detailed rules explaining key parameters and behaviors
 - This helper is useful when generated setup should preserve both sink/logger behavior and async runtime behavior together.
 - The exported `logger` section keeps the full `LoggerConfig` shape, including fields that only matter on the full sync-first builder path such as the optional sync queue layer.
 - That means the JSON shape is broader than the consumption pattern of `build_async_text_logger(...)`, which only uses selected text-oriented logger fields when building the sink.
+- In particular, the exported `logger.sink.kind` remains whatever the config currently says, but a later `build_async_text_logger(...)` call still ignores that sink-kind branch and constructs `FormattedConsoleSink` from `logger.sink.text_formatter`.
 
 ### How to Use
 
@@ -63,6 +64,8 @@ In this example, both layers of configuration are exported together.
 
 And later consumers can still choose whether to rebuild through `build_async_logger(...)` or the narrower `build_async_text_logger(...)` path.
 
+And that later text-specific builder choice still matters more than the serialized `logger.sink.kind` value, because only the formatter-backed text path is consumed there.
+
 #### When Need Roundtrip-friendly Build Config Data
 
 When generated build config should later be parsed again:
@@ -81,6 +84,8 @@ e.g.:
 
 - Exporting the full `logger` section does not imply that every async builder will later consume every logger field equally.
 
+- Exporting `logger.sink.kind="file"` or `"console"` also does not force the later text-specific builder path to branch that way; only `build_async_logger(...)` follows sink kind when constructing the runtime sink.
+
 ### Notes
 
 1. Use this helper when tools or tests need a structured JSON object instead of text.

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

@@ -43,6 +43,7 @@ Detailed rules explaining key parameters and behaviors
 - Internally it serializes the `JsonValue` result with `@json_parser.stringify(...)` or `@json_parser.stringify_pretty(value, 2)`, so the text form stays aligned with the structured async build-config export helper.
 - The output keeps `logger` and `async_config` as separate sections, matching supported parser input.
 - The serialized `logger` section preserves the full `LoggerConfig` shape, even though `build_async_text_logger(...)` later consumes only the selected text-oriented subset of that logger config.
+- That includes preserving whatever `logger.sink.kind` text is present in the config, even though the later text-specific builder path still ignores that sink-kind branch and constructs `FormattedConsoleSink` from `logger.sink.text_formatter`.
 
 ### How to Use
 
@@ -59,6 +60,8 @@ In this example, the full build configuration is rendered as readable JSON.
 
 And the resulting text still describes a shared config object that can feed either async builder path later.
 
+And if later code chooses `build_async_text_logger(...)`, that choice still matters more than the serialized `logger.sink.kind` text because only the formatter-backed text path is consumed there.
+
 #### When Need Compact Generated Build Config
 
 When config text should stay small for snapshots or transport:
@@ -85,5 +88,7 @@ e.g.:
 
 3. The serialized shape round-trips through `parse_async_logger_build_config_text(...)`, but the later builder choice still controls whether the full sync config path or only the text-oriented subset is consumed during construction.
 
-4. Use `async_logger_build_config_to_json(...)` when the next consumer still needs a `JsonValue` for composition before final stringification.
+4. In particular, serialized `logger.sink.kind` text is descriptive config data, not a guarantee that the text-specific builder path will branch on that sink kind later.
+
+5. Use `async_logger_build_config_to_json(...)` when the next consumer still needs a `JsonValue` for composition before final stringification.