Windows: reemit publishes the late rows alone, so the Postgres example drops

[turbolytics]

What this changes

bluesky.postgres.windowed.yml pairs late_rows: reemit with an upsert that replaces the count:

ON CONFLICT (bucket, lang) DO UPDATE SET posts = EXCLUDED.posts

A close deletes the bucket's rows, so reemit runs emit_sql over the late rows alone. The upsert then replaces a published minute's count with the late rows' count. One late post replaces the minute's count with 1.

• The example declares late_rows: drop.
• The README, the config schema, the example comments, ParseLatePolicy's message and validate's reemit warning said reemit publishes the bucket again, for a sink that upserts. That is the pairing that loses the count. They now say reemit publishes emit_sql over the late rows, for a sink that adds them to the bucket it holds.
• TestManagerWindow_ReemitPublishesTheLateRowsAlone pins the behaviour the docs describe.

If this is wrong, the docs steer a user with a replacing upsert away from reemit when it would have kept the count.

Verification

• go test -short -race ./...: pass, no FAIL lines. go vet ./... is clean.
• uv run --locked pytest tests/tooling -q: 205 passed.
• make coverage-page && git status --short docs/coverage: clean.
• uv run --locked pytest tests/release -q: not run. No flag, CLI command or build stamp changed; the schema changed one description.
• make soak: not run. watermark.go changed a comment and an error string, and nothing on the consume loop, a handler, a sink or the allocation path changed.

The late-row claim, against the published turbolytics/sql-flow:v2026.09.14, a webhook source, and a replacing upsert into Postgres 18. Five posts closed a minute, then one late post arrived for it:

late_rows	Count after the close	Count after the late post	window_late_rows_total
reemit	5	1	1
drop	5	5	1

The new test fails when reemit republishes the whole bucket. With the close's delete removed:

--- FAIL: TestManagerWindow_ReemitPublishesTheLateRowsAlone (0.03s)
    watermark_test.go:223: [][]string{[]string{"5"}, []string{"6"}} != [][]string{[]string{"5"}, []string{"1"}}

Soak verdict

Not run; see above.

Notes for the reviewer

• The spec for Windows owned by the engine: a watermark manager and a late-row policy #281 said reemit "is today's behaviour, for sinks that upsert". The old predicates overwrote the same way: a late row matched the collect on the next poll and replaced the count. The spec is a record of the design, so this PR leaves it as written.
• An upsert that adds, SET posts = t.posts + EXCLUDED.posts, makes reemit complete but counts a republished close twice. No sink makes reemit exact today; the README says so by pointing at Guarantees.
• The CHANGELOG entry sits under a new ## Unreleased, above the heading changelog: name the v2026.09.14 section #286 names v2026.09.14. Whichever merges second keeps both.
• The bluesky demo hit this while moving to v2026.09.14 and declares drop: pipeline: declare the window for sql-flow v2026.09.14 sql-flow-bluesky-demo#4.