Clarify async companion status

Author: eldryoth

README.md

@@ -215,7 +215,7 @@ license = "MIT OR Apache-2.0"
 | `stream` | no | `std::io` streaming wrappers. |
 | `allow-wasm32-best-effort-wipe` | no | Explicitly allow `wasm32` builds with compiler-fence-only cleanup. |
 | `allow-compiler-fence-only-wipe` | no | Explicitly allow unsupported native architectures to build with compiler-fence-only cleanup after platform review. |
-| `tokio` | no | Reserved for future async streaming wrappers; currently inert and dependency-free. |
+| `tokio` | no | Reserved placeholder in the core crate; currently inert and dependency-free. Use `base64-ng-tokio` for the admitted async helper and streaming adapter surface. |
 | `kani` | no | Reserved for verifier harnesses; normal builds do not require Kani. |
 | `fuzzing` | no | Reserved for verifier and fuzz harness integration; published crate stays dependency-free. |
 
@@ -1123,7 +1123,7 @@ Security commitments:
 - [docs/ASYNC.md](docs/ASYNC.md) defines the admission bar for async/Tokio
   APIs. The optional companion crate now admits read-all/write-all helpers and
   manual `AsyncRead`/`AsyncWrite` streaming adapters; the core `tokio` feature
-  remains deferred and inert.
+  remains reserved and inert.
 - [docs/DEPENDENCIES.md](docs/DEPENDENCIES.md) defines the dependency
   admission bar for any future external crate.
 - `runtime::backend_report()` exposes the active admitted backend, detected

docs/PLAN.md

@@ -39,9 +39,13 @@ Allowed without adding dependencies:
 
 External crates require written justification before inclusion:
 
-- `tokio` may be accepted only behind the optional `tokio` feature for async stream wrappers.
-- `serde` may be accepted only behind an optional feature after API and dependency review.
-- `bytes` may be accepted only behind an optional feature after API and dependency review.
+- `tokio` remains excluded from the core crate; admitted Tokio integration lives
+  in the optional `base64-ng-tokio` companion crate after async API,
+  cancellation, backpressure, and dependency review.
+- `serde` may be accepted only behind an optional integration crate or feature
+  after API and dependency review.
+- `bytes` may be accepted only behind an optional integration crate or feature
+  after API and dependency review.
 - `zeroize` remains rejected by default; the current direction is an internal
   best-effort wiping helper and secret wrapper types before considering a
   dependency.
@@ -993,9 +997,9 @@ those expensive wrapped/public-surface harnesses for background runs.
 - CT-oriented secret decode remains scalar unless a separate formal
   side-channel evidence package proves otherwise. Do not route CT decode
   through normal SIMD decode.
-- Tokio read-side streaming exists only if the cancellation/drop/buffering
-  evidence is complete. Tokio writer streaming remains explicitly deferred for
-  `1.3.0` unless a later slice admits it separately.
+- Tokio reader and writer streaming exist in `base64-ng-tokio` only because the
+  cancellation/drop/buffering evidence is complete for that companion crate.
+  The core crate's `tokio` feature remains inert.
 - Const decode exists with a clear strict `Result` contract and does not add a
   runtime panic surface.
 - Kani, fuzz, Miri, dudect, generated assembly, benchmark, unsafe-boundary,

release-notes/RELEASE_NOTES_1.3.3.md

@@ -41,6 +41,9 @@ wasm `simd128` runtime-dispatch profile with explicit runtime smoke evidence.
   before admitted strict decode backend use, preserving overlap safety by
   copying encoded chunks into fixed scratch buffers before writing decoded
   bytes behind the unread input cursor.
+- Aligned roadmap and README wording with the current async split: the core
+  `tokio` feature remains inert, while `base64-ng-tokio` is the admitted
+  async helper and streaming adapter surface.
 - Added release-gated wasm SIMD codegen evidence through
   `scripts/generate_wasm_simd_evidence.sh`, which emits test-harness LLVM IR
   with `target-feature=+simd128` when the wasm target is installed.