Configurable re-auth window

○ planned

Decide whether verification happens for every statement, every session, or somewhere comfortably in between.

Choose how long one verification stays good for. Ask on every statement for the targets where that is proportionate, or once per session - or for a few minutes - where it is not.

The trade-off, stated plainly

A shorter window is stronger and more annoying; a longer one is the opposite. The failure mode of a too-short window is not “more security” - it is a prompt you learn to approve without reading, which is worse than no prompt at all. Pick the longest window you would still be comfortable explaining.

Window	Fits
Every statement	A production database you touch a handful of times a month. Each write is its own decision.
A few minutes	A maintenance session: verify once, do the run of related work, and let it re-lock itself while you write up what you did.
Per session	A machine you trust, where the gate is mostly about not connecting to the wrong thing in the first place.

A window never survives the app. Verification state is held in memory for the session only - it is never written to disk and never restored on the next launch. This mirrors how the production write unlock already behaves: quitting SQLly always re-locks everything.

Planned. The design follows the production write unlock, which already ships with 1-, 5-, and 15-minute windows and a counting-down status-bar chip - that is the model this will follow.