feat(security): W3.1 PR A — SQL parameter classifier + prepared template rewriter (helpers only)

[jrosskopf]

Summary

First slice of the W3.1 prepared-statement refactor (#25). This PR adds the two pure helpers the rest of W3.1 will build on — NO integration with the query path yet, NO behavioural change for any existing endpoint. The aim is to let reviewers verify the security-critical logic in isolation before the larger query-path change lands.

PR B (separate, follow-up) will wire these into DatabaseManager behind a per-endpoint opt-in flag with the full integration test surface (see below).

What ships in this PR

1. SqlParameterClassifier — pure helper

Maps a RequestFieldConfig validator to (bindable, SqlParameterType):

• int/integer → Integer
• number/float/double → Double
• boolean/bool → Boolean
• date → Date
• time → Time
• uuid/string/email/enum → Varchar
• no typed validator → not bindable (conservative; Mustache stays the safe default)
• unknown validator name → not bindable (forward-compat: a future validator type can't accidentally land on the prepared path)

2. PreparedTemplateRewriter — pure helper

Scans a Mustache template, rewrites {{ params.X }} → ? for bindable X at section depth 0, records binding order. Leaves alone:

• Triple-brace {{{ params.X }}} (operators migrate these separately)
• Anything inside {{#X}}...{{/X}} or {{^X}}...{{/X}} (any depth)
• Params with no typed validator
• Non-params.* references like {{ conn.X }}, {{ env.X }}, {{ auth.X }}
• Malformed / unterminated tags (passthrough, no crash)

Test plan (~45 Catch2 cases, all green)

Classifier ([security][prepared][classifier])

Every validator type, multiple-validator fallback (first known wins), case sensitivity, whitespace intolerance, large validator lists, determinism across calls, empty fields, forward-compat (unknown name before known doesn't block).

Rewriter ([security][prepared][rewriter] + [edge])

Empty template, no params, single bindable param, triple-brace passthrough, unknown field passthrough, section suppression (positive {{#}}, inverted {{^}}, nested), stray {{/X}} clamps to depth 0, unterminated tags (passthrough, no crash), no-whitespace form {{params.X}}, very wide binding count (25 distinct), multi-line templates, idempotency, repeated param becomes two bindings, and a pinning test proving an injection-style value would land in a bound ? rather than being expanded into syntax.

ctest -R "PreparedTemplateRewriter|SqlParameterClassifier" — 46/46 pass.

What this PR does NOT ship (deliberate, lands in PR B)

• DatabaseManager::executeQuery integration (no duckdb_prepare / duckdb_bind_* yet)
• EndpointConfig.use-prepared-statements opt-in flag
• Cache-layer interaction
• Pagination interaction (LIMIT / OFFSET binding)
• Write-path integration (executeWrite, executeWriteInTransaction)
• Companion W3.3 work (demoting the regex SQL-injection validator)
• Full integration tests against a real flapi binary

PR B testing plan (committed deliverable, NOT part of this PR)

To address the "thoroughly tested with full integration tests" concern up front:

• C++ integration test running real DuckDB prepared queries for each SqlParameterType with a value that would have been an injection attempt under Mustache (e.g., 1; DROP TABLE customers -- bound as Varchar → zero rows, no DROP).
• C++ integration test comparing rendered SQL + result rows of the same endpoint with and without use-prepared-statements: true for a corpus of templates copied from test/integration/api_configuration/sqls/.
• Python E2E tests that boot a real flapi server, hit endpoints in both modes, and diff responses.
• Cache-enabled endpoint test, write-endpoint test, paginated endpoint test — each in both modes.
• Adversarial test corpus: historical SQL-injection payloads applied to bindable params, asserting each is rendered inert.

Closes part of #25 (PR A of three planned)
Refs #21