📝 clarify logger context field binding

docs/api/logger-with-context-fields.md

@@ -37,6 +37,7 @@ Detailed rules explaining key parameters and behaviors
 - Context fields are merged at write time, not by mutating previously created records.
 - When a log call also passes per-record fields, the context fields are placed before those per-call fields.
 - This API returns a new typed logger wrapper; it does not mutate the original logger variable.
+- The returned logger keeps the same stored target, min level, and timestamp behavior while extending the sink pipeline with context-field merging.
 - `bind(...)` is an ergonomic alias for this same behavior.
 
 ### How to Use
@@ -57,6 +58,8 @@ In this example, both `service` and `region` are automatically included on every
 
 And callers only need to provide fields that actually vary per event.
 
+The original base logger value is still unchanged if later code keeps using it directly.
+
 #### When Build Child Loggers For Subsystems
 
 When a subsystem has both a target and fixed fields:
@@ -81,3 +84,5 @@ e.g.:
 
 2. Prefer `fields([("k", "v")])` when you want a more ergonomic call site.
 
+3. Use `bind(...)` when you want the same behavior with a shorter, library-style call name.
+