Harden SQL handling against injection; document safe-query rules.

[UnityZappy]

The report path executes SQL via ExecuteQuery(string sql), which Cycode SAST flagged as unsanitized input. All callers pass internally-constructed SQL (ReportSql constants; DownstreamStats interpolates a numeric long), so there is no live injection vector — but the dynamic-SQL builders were inconsistent and the sink had no least-privilege control. This tightens both and codifies the rules so they stay enforced.

Code:

• Open report/analysis DB connections read-only (SQLite Mode=ReadOnly, DuckDB ACCESS_MODE=READ_ONLY) so a malformed query reaching ExecuteQuery cannot modify or drop data; export writers stay read-write. Covers Sqlite/DuckDbReportQueries, MultiSnapshotReportBuilder, SummaryReportRunner.
• DuckDbReportQueries.HasColumn: replace quote-escaped identifier interpolation with positional bind parameters against information_schema.columns.
• MultiSnapshotReportBuilder: bind the native-type filter value as a parameter (DuckDB '?', SQLite '$nativeType') instead of interpolating it.
• Document the ExecuteQuery trust/read-only contract on IReportQueryBackend.

Docs & guidance:

• Add docs/sql-safety.md (best practices for SQLite + DuckDB) and wire it into the mkdocs nav.
• Add CLAUDE.md with the enforced project rule for SQL handling.
• Add SECURITY.md with reporting policy and a triage-log entry for the Cycode finding (disposition: false positive; mitigations + Unity suppression steps).

Verified: build clean, 19/19 tests pass, and report/summary/multi-report run end-to-end on real DuckDB and SQLite databases over read-only connections.