fix: stop --ingest's NULL sentinel from clobbering post content

UpsertPostFromTextFile (the persistence layer under --ingest) uses NULL as
its "this file's record had no line for that field" sentinel -- the direct
analog of the "." convention just fixed in UpdatePost. IngestMode strips a
trailing "_N" off the folder name before it ever reaches this function, so
a duplicate export folder deliberately collapses onto the same BlogName --
reconciling multiple differently-formatted files for one post is the whole
point of --ingest. Files are walked in raw filesystem enumeration order,
never sorted, so which file's call lands last for a given (BlogName,
PostID) is arbitrary.

The UPDATE branch set every column unconditionally, so whichever file
processed last for a PostID nulled out every field its own record didn't
carry, silently erasing real content another file had. Worse than the "."
case: that one only caused churn (two writes cancelling out); this one
loses data, in an order that depends on filesystem enumeration.

Every content column is now guarded the same way, NULL instead of "." as
the sentinel: `col = CASE WHEN @col IS NULL THEN col ELSE @col END` in the
SET list, `(@col IS NOT NULL AND IFNULL(col,'') <> @col) OR ...` in the
change-detection. Narrow the same way: only a missing line (NULL) is the
sentinel -- G() already distinguishes that from present-but-blank (""), so
an explicit empty field still overwrites.

HasImage is deliberately left unguarded and documented as a known gap:
IngestMode always computes a concrete bool, defaulting false when a file
has no "Has Image:" line, so this function can't currently tell "no image"
from "not reported" without changing the parameter to bool? and threading
that through IngestMode/LegacyPostsDbImporter too.

Verified against a throwaway DB using the exact SQL text and parameter
binding: a full-format record's real Title/Slug/Tags now survive a
same-PostID partial record whose format doesn't carry those fields, in
both file orders, while a genuine content change and an explicit empty
value still write and still move DateModified.

Co-Authored-By: Claude Opus 5 <[email protected]>

AGENTS.md

@@ -124,6 +124,36 @@ though the true content never changes.
   source can legitimately supply `"."` as "field absent" before deciding whether it needs
   the same `CASE` treatment — don't assume every column needs it
 
+**`--ingest` (`UpsertPostFromTextFile`) uses `NULL`, not `"."`, for the same "field absent"
+convention, and reconciling exactly this kind of duplicate IS the feature's job.**
+`IngestMode` strips a trailing `_N` from the folder name before it ever reaches
+`UpsertPostFromTextFile`, so a duplicate export folder collapses onto the same `BlogName` on
+purpose — the whole point is to merge multiple differently-formatted files for the same post
+into one row. `IngestMode.G(key)` returns `null` (not `"."`) when a field's line is absent
+from a given file, `LegacyPostsDbImporter` passes `null` straight from a `NULL` source column,
+and files are walked in raw filesystem enumeration order — never sorted — so which file's call
+lands last for a given `(BlogName, PostID)` is arbitrary.
+
+- Before the fix, the `UPDATE` branch set every column unconditionally, so whichever file
+  processed last for a `PostID` would null out every field its own record didn't carry —
+  silently erasing real `Title`/`Slug`/`Tags`/… another file had, the opposite of what
+  `--ingest` exists to do. This is worse than the `"."` case above: that one only caused
+  churn (the two writes canceled out); this one loses data, and which posts lose which
+  fields depends on filesystem enumeration order
+- Same shape of fix, `NULL` instead of `"."` as the sentinel: `col = CASE WHEN @col IS NULL
+  THEN col ELSE @col END` in the `SET` list, `(@col IS NOT NULL AND IFNULL(col, '') <> @col)
+  OR ...` in the change-detection
+- Same narrow rule: only `NULL` (the field's line was never present in this file) is the
+  sentinel. `G()` already distinguishes this from "present but blank" — a dictionary miss is
+  `null`, an empty value after the prefix is `""` — so an explicitly blank field still
+  overwrites
+- `HasImage` is **not** guarded and remains a known gap: `IngestMode` always computes a
+  concrete `bool` (defaulting `false` when a file has no `Has Image:` line), so there is no
+  way for this function to tell "this format says no image" from "this format doesn't report
+  it at all" without changing the parameter to `bool?` and threading that through
+  `IngestMode`/`LegacyPostsDbImporter`. Fix this the same way if `--ingest` is observed
+  downgrading a post's `HasImage` from `1` to `0`
+
 ### Testing
 - No existing test suite; use xUnit if adding tests
 - Test critical logic: `ApiKeyPool` init, color parsing, config persistence