Fix task log persistence on Postgres and harden the log flush path

[damilolaedwards]

Problem

Two related problems in the task log persistence path, both specific to the write to the database. SQLite, the default engine, was not affected by the first one.

Task logs are never stored on Postgres

InsertTaskLog upserts with ON CONFLICT (run_id, task_id, log_time), but the only unique key on task_logs is the primary key (run_id, task_id, log_idx); there is no unique index on log_time. Postgres rejects an ON CONFLICT target that does not match a unique or exclusion constraint, so every task log insert fails on Postgres at execution time and no task logs are ever stored. The SQLite branch uses INSERT OR REPLACE keyed by the primary key and works.

The flush path fails badly on any flush error

Whenever a flush fails (on Postgres, every time), three things went wrong:

• The failure was logged through the writer's own logger, whose database hook re-enters Fire and tries to take the buffer mutex that the flush already holds, so the logging goroutine deadlocks.
• The buffer was only cleared on success, so on a persistent failure it grows without bound.
• The flush coordination used a shared cancellation channel that could be closed twice and panic.

Fix

• Point the upsert conflict target at the primary key (run_id, task_id, log_idx), which both engines share.
• Rewrite the flush coordination around the buffer mutex and a single scheduled flag. The buffer is always cleared after a flush attempt, so a failing database cannot grow it without bound. Flush errors are reported through the parent logger instead of the writer's own logger, so they cannot re-enter the hook. The cancellation channel is removed: a delayed flush simply finds an empty buffer if an earlier flush already ran, which also removes the double close.

Tests

• Database layer: a task log is persisted and re-inserting the same primary key updates the row in place rather than duplicating or failing.
• Logger: against a database whose table does not exist so every flush fails, logging keeps making progress and the buffer stays bounded; and on a working database, entries logged through the scope are persisted on flush.

go build ./..., go vet, and the logger and db packages under -race pass.