Supabase v2 builder discards encryptionError — EncryptedSupabaseError.encryptionError is always undefined

[coderdan]

Summary

The v2 encryptedSupabase query builder's catch block hardcodes
encryptionError: undefined when constructing the EncryptedSupabaseError, so
the populated value is discarded even when the caught error is an encryption
failure. The typed EncryptedSupabaseError.encryptionError field
(packages/stack/src/supabase/types.ts:356) is therefore always undefined and
callers cannot branch on it.

Location

packages/stack/src/supabase/query-builder.ts:413-422

} catch (err) {
  const message = err instanceof Error ? err.message : String(err)
  logger.error(
    `Supabase encrypted query failed on table "${this.tableName}": ${message}`,
  )

  const error: EncryptedSupabaseError = {
    message,
    encryptionError: undefined,   // <-- always undefined; `err` is never inspected
  }
  ...

Impact

• error.encryptionError is dead — a documented field that never carries a value.
• Callers currently have to distinguish encryption failures indirectly (e.g.
  status === 500 && statusText === 'Encryption Error', or .throwOnError()),
  which the stash-supabase skill now documents as a caveat.

Suggested fix

When the caught err is (or wraps) an EncryptionError, thread it into
encryptionError instead of hardcoding undefined; otherwise leave it unset.
Add a unit test asserting error.encryptionError is populated on a genuine
encryption failure (e.g. wrong index / unencryptable operand) and absent on a
plain PostgREST/API error.

Notes

• Surfaced while rewriting the stash-supabase skill (PR docs(supabase): correct the stash-supabase skill #606); the skill retains
  a caveat pointing here until this is fixed.
• The equivalent v3 builder path should be checked for the same pattern.

[coderdan]

Resolved by #634 (EncryptedSupabaseError.encryptionError now populated), merged into the 1.0 candidate #535.