Harden authentication and protect sensitive tokens

[BigSimmo]

Problem

• requireAuthenticatedUser falls back to a local “no-auth” mode if no bearer token is supplied, using cached owner‑ID lookups or deriving the owner from the last imported document. This bypass allows unauthorised access if an attacker crafts requests without tokens.
• The front-end persists Supabase refresh tokens and the user’s email in browser localStorage, leaving them vulnerable to cross‑site scripting (XSS) or multi-user environment leaks.
• The ingestion pipeline automatically uploads and captions images and stores captions and classification metadata in the database. If the image‑classification model misclassifies an image (e.g. a patient identifier), the caption may include sensitive text that is stored unredacted.
• Several scripts still log Supabase errors with full details, and those logs may be sent to third-party monitoring. This can expose sensitive data (document names, user IDs).

Recommendations

• Remove the no-auth fallback in production and always validate bearer tokens against Supabase auth. Ensure that all routes require proper authentication.
• Store session tokens in secure cookies (e.g. HttpOnly and SameSite=Lax) or use in-memory session storage instead of localStorage to reduce the risk of token theft.
• Introduce a manual review or filtering step before persisting generated captions. De-identify or redact potential identifiers in the captions.
• Use the existing safeErrorLogDetails helper consistently across the codebase to redact sensitive paths, URLs and secrets before logging. Avoid logging full Supabase error details to external services.