security: define grammar-specific control-character contracts for DSN, SQL, DBML, and annotation bodies

[seonghobae]

Buyer/security gap

PR #926 surfaced a valid but separate question beyond identifier log-safety: structured and free-form text inputs (dsn, forward DDL SQL, DBML source, annotation body) need explicit character contracts. A blanket identifier regex is not suitable because these fields have different grammars and legitimate formatting requirements.

Required decisions

1. DSN

   • Parse with the supported PostgreSQL/Snowflake DSN grammar rather than treating it as an arbitrary display string.
   • Determine whether CR/LF, NUL, C0/C1, U+2028, and U+2029 are rejected by parser contract, transport contract, or explicit validation.
   • Preserve secret redaction and avoid logging the raw DSN.

2. Forward DDL SQL

   • Preserve required horizontal tab/newline/carriage-return formatting if the accepted grammar allows it.
   • Reject NUL and characters that cannot occur in the bounded DDL grammar.
   • Keep full DDL semantic validation in the existing authoritative validation boundary; do not add a second validator in a request model unless the architecture proves that boundary is canonical and non-circular.

3. DBML source

   • Preserve legal multiline formatting.
   • Reject characters that the DBML parser cannot represent deterministically.
   • Verify error messages and logs never echo hostile raw input.

4. Annotation body

   • Continue supporting multiline human-authored text.
   • Treat storage validation, log safety, HTML/Markdown rendering escape, and export safety as distinct controls.
   • Do not destructively rewrite customer text merely to simplify logging.

Implementation constraints

• Split this work from identifier validation PR fix(security): reject log-breaking identifier characters #887.
• Start with failing tests for each grammar and each actual sink.
• Verify prefix/middle/suffix placement and positive multilingual cases.
• Include C0, DEL, C1, U+2028, and U+2029 only where the field’s documented grammar and sink analysis justify them.
• No unrelated workflow, dependency, lockfile, relationship-inference, or frontend drift.
• Update CHANGELOG.md, docs/doctoring/, and docs/product-technical-gap-baseline.md with the decision and residual risks.
• Required exact-head backend, coverage, SAST, supply-chain, Strix, and OpenCode evidence remains mandatory.

Source disposition

PR #926 mixes the above candidate scope with identifier changes already superseded by #887, a DDL semantic-validator relocation, a linter cleanup, workflow changes, and dependency drift. Preserve the finding through this issue, not by merging the mixed branch.