vimgitai bolts a second lock onto the client data vault

A full security review found the fork's most sensitive tables were guarded by a single rule, and vimgitai's proposed fix adds a database-level backstop so one slip can't expose live legal data.

The review turned up a quiet gap: the backend tables holding documents, chats, tabular reviews, projects, workflows and more were protected only by one blanket permission rule, and an assumed "second layer" had never actually been switched on. The worry is simple - one forgotten setting on one new table, and confidential client data could be readable through a public access key.

The pull request, still open, bundles two hardening moves:

Zero-rows-by-default isolation: it forces row-level security (a database feature that hands back no data unless a caller is explicitly allowed) on all fourteen sensitive tables, so anonymous or general callers get nothing by construction - and future tables inherit the same lockdown automatically.
Dependency cleanup: it patches known high-severity flaws in two backend components, cutting the reported vulnerability count from twelve to two, with the build confirmed clean.

vimgitai is clear this is belt-and-suspenders, not a new feature: nothing changes for the app, and the database migration must be run separately before merging.