cq sql prints a scope banner but silently ignores --project/--source; also a lexical timestamp trap

`cq sql` prints `Scoped to ~/pickleton` and `Scoped to source 'main'` banners, implying the raw SQL query that follows is filtered accordingly. It isn't: results span every project and every source regardless of the `--project`/`--source` flags.

There's a second, separate trap: `timestamp` is stored as a `VARCHAR` (e.g. `2026-08-11T17:48:17.818Z`) and compared lexically, so an upper bound like `timestamp <= '2026-08-11 23:59:59'` (space instead of `T` separator) sorts below every real timestamp that day because `' '` (0x20) < `'T'` (0x54), so the entire day silently disappears from results with no error.

Expected: either the banner's claimed scoping should actually apply to the query, or the banner shouldn't imply it does. The timestamp comparison should use `T` consistently or compare as a real timestamp type, not lexically.

Repro: run any `cq sql` query with `--project`/`--source` set, and a second query that filters `timestamp <= 'YYYY-MM-DD 23:59:59'` (space, not `T`); compare against a query using the `T`-separated form for the same day.

Re-verified live 2026-09-02: `cq sql "select count(*) as n from sessions"` returns identical counts with and without `--project pickleton` set.

Start at the cq sql entry point and trace how --project and --source are handled when the raw SQL query is built or executed. Reproduce the scoped and timestamp queries described in the issue, then verify that scope affects results and that space- and T-separated timestamp bounds behave consistently.