docs(stack-supabase): clarify v2 decrypt path in changeset

v2 read via this adapter is intentionally removed; v2 ciphertext still
decrypts through the core @cipherstash/stack client. Mixed-generation
handling is customer-side (install both), per #707 out-of-scope stance.

Author: tobyhede

.changeset/remove-eql-v2-supabase-authoring.md

@@ -23,9 +23,15 @@ unsuffixed names (part of the EQL v2 removal, #707).
   the rest of the `*V3` key-helper types. Each keeps a type-identical
   `@deprecated` `*V3` alias.
 
-**Not affected: reading existing data.** Only the v2 *authoring/emission* surface
-is removed. Decryption in `@cipherstash/stack` is generation-agnostic, so rows
-written as EQL v2 payloads still decrypt through the wrapper's read path.
+**Reading existing v2 data.** Only the v2 *authoring/emission* surface is removed
+— no v2 ciphertext is stranded. Decryption in `@cipherstash/stack` is
+generation-agnostic, so EQL v2 payloads still decrypt through the core client
+(`decrypt` / `decryptModel`). This adapter, however, is now EQL v3 only and will
+not auto-read an `eql_v2_encrypted` column: to read legacy v2 data during
+migration, decrypt fetched rows with `@cipherstash/stack` directly, or run a
+v2-configured setup alongside the v3 one and route per column. Mixed-generation
+handling is a customer-side concern (install both and handle it explicitly), not
+adapter auto-detection.
 
 Internally the v3 query builder (`query-builder-v3.ts`) was folded into the base
 `EncryptedQueryBuilderImpl`, which is now natively EQL v3; no runtime behaviour or