fix(db): default documents.meta_date_precision to UNKNOWN in V69

The V69 migration added documents.meta_date_precision as NOT NULL with no
DB default. Raw-SQL inserts that omit the column (test fixtures, ad-hoc
loads) hit a not-null violation — 33 backend CI errors all reading
"null value in column meta_date_precision ... violates not-null constraint".

Add DEFAULT 'UNKNOWN' to the ADD COLUMN so omitting-column inserts get a
sane, CHECK-valid value. Existing rows still get backfilled (DAY when
meta_date present, else UNKNOWN) before SET NOT NULL; CHECK constraints
unchanged. Entity already sets it via @Builder.Default = DatePrecision.UNKNOWN,
so JPA saves stay consistent. Editing V69 in place is safe: unmerged,
no shared DB has applied it.

Refs #671

backend/src/main/resources/db/migration/V69__import_precision_attribution_identity_schema.sql

@@ -24,9 +24,12 @@ ALTER TABLE documents ADD CONSTRAINT chk_meta_date_raw_length CHECK (length(meta
 ALTER TABLE documents ADD CONSTRAINT chk_sender_text_length CHECK (length(sender_text) <= 10000);
 ALTER TABLE documents ADD CONSTRAINT chk_receiver_text_length CHECK (length(receiver_text) <= 10000);
 
--- Precision enum — added nullable, backfilled, then made NOT NULL (in this order so the
+-- Precision enum — added with a DB default of 'UNKNOWN', backfilled, then made NOT NULL.
--- backfill can populate existing rows before the constraint is enforced).
+-- The DEFAULT serves two purposes: (1) existing rows get 'UNKNOWN' immediately, and
-ALTER TABLE documents ADD COLUMN meta_date_precision varchar(16);
+-- (2) raw-SQL inserts that omit the column (test fixtures, ad-hoc data loads) get a sane,
+-- CHECK-valid value instead of violating the NOT NULL constraint. JPA saves still set it
+-- explicitly via the entity's @Builder.Default = DatePrecision.UNKNOWN.
+ALTER TABLE documents ADD COLUMN meta_date_precision varchar(16) DEFAULT 'UNKNOWN';
 
 UPDATE documents
 SET meta_date_precision = CASE WHEN meta_date IS NOT NULL THEN 'DAY' ELSE 'UNKNOWN' END;