test(scripts),docs(skills): retire the guard this fix falsifies

`scripts/__tests__/skills-supabase-edge-schema-entry.test.mjs` (#951) failed
any shipped document whose snippet paired `encryptedSupabase` from
`@cipherstash/stack-supabase/wasm-inline` with `encryptedTable`/`types` from
`@cipherstash/stack/wasm-inline`, on the stated grounds that the pairing "does
not compile: ... TS2322, separate declarations of a private property
'columnName'".

That sentence is false as of the previous commit. Making the pairing compile is
the whole point of it, `dist-types/wasm-inline-type-identity.ts` now asserts it
compiles, and `stash-supabase` actively recommends it. The guard passed only
because no fence literally showed the pairing — `stash-edge` smuggled it in as a
trailing comment, which is a document dodging its own lint. The first person to
write the example the skill recommends would have been blocked by a guard citing
a compiler error that no longer happens.

Deleted rather than reworded. The obvious repurposing — assert the docs carry
the version caveat — guards prose phrasing, which drifts by legitimate rewording
rather than by defect, and it could only ever fire in a world where the compile
property is already broken. `wasm-inline-type-identity.ts` catches that first,
in the codebase, by type-checking rather than text-matching.

The property the guard protected is now held there, in the correct direction:
the adapter types `schemas` as `Record<string, AnyV3Table>` with `AnyV3Table`
from `@cipherstash/stack/eql/v3` (`schema-builder.ts:7`), which is the same
declaration the gate asserts assignability to. Recorded in that file's comment
so the reason the guard went lives where the property is kept, rather than only
in this message. Asserting through `encryptedSupabase` itself was considered and
rejected: it would give `packages/stack`'s declaration gate a build-graph
dependency on a package that depends on it.

`lib/package-readmes.mjs` keeps three other consumers, so nothing is orphaned.

`stash-edge` now shows the wasm-inline pairing as a real fence beside the
`eql/v3` one, which is what the smuggled comment was avoiding.

Refs #963

Claude-Session: https://claude.ai/code/session_01HAonmKdSJMxYZcuRCiZPXE

Author: tobyhede

packages/stack/dist-types/wasm-inline-type-identity.ts

@@ -55,6 +55,22 @@ const wasmUsers = wasmEncryptedTable('users', {
  * The assertion. Every first-party adapter types its `schemas` option in terms
  * of `AnyV3Table`, so a wasm-inline-authored table that is not assignable here
  * cannot be passed to `encryptedSupabase`, the Drizzle helpers, or Prisma Next.
+ *
+ * `@cipherstash/stack-supabase` is the concrete case, and this line is what
+ * replaced a text-level guard over it. `V3Schemas = Record<string, AnyV3Table>`
+ * (`packages/stack-supabase/src/schema-builder.ts:7`) imports `AnyV3Table` from
+ * `@cipherstash/stack/eql/v3` — the same declaration resolved here — so pinning
+ * assignability to it pins the adapter pairing too, without this package taking
+ * a build-graph dependency on one that depends on it.
+ *
+ * `scripts/__tests__/skills-supabase-edge-schema-entry.test.mjs` used to grep
+ * shipped docs for a snippet pairing `encryptedSupabase` from the adapter's
+ * wasm-inline entry with `encryptedTable`/`types` from
+ * `@cipherstash/stack/wasm-inline`, on the grounds that it did not compile. It
+ * compiles now, and that is the point of this file — so the guard was deleted
+ * rather than reworded. A guard asserting a false claim is worse than no guard:
+ * it would have blocked the first person to write the example the `stash-edge`
+ * skill now recommends, citing a compiler error that no longer happens.
  */
 export const wasmTableIsAV3Table: AnyV3Table = wasmUsers
 

scripts/__tests__/skills-supabase-edge-schema-entry.test.mjs

@@ -433,10 +433,16 @@ longer: every entry now resolves one declaration of the column classes, so
 either import works and both examples below are correct.
 
 ```ts
-// The engine is WASM either way. The schema's declaration site no longer matters.
+// Both of these compile. The engine is WASM either way.
 import { encryptedSupabase } from '@cipherstash/stack-supabase/wasm-inline'
 import { encryptedTable, types } from '@cipherstash/stack/eql/v3'
-// …or from '@cipherstash/stack/wasm-inline' — same classes, same result.
+```
+
+```ts
+// The same, authored from the edge entry — useful when this module is also
+// imported by the Edge Function, so one table definition serves both sides.
+import { encryptedSupabase } from '@cipherstash/stack-supabase/wasm-inline'
+import { encryptedTable, types } from '@cipherstash/stack/wasm-inline'
 ```
 
 On a version predating that fix the old rule still applies: author from