perf(thread-store): project append metadata asynchronously

[apanasenko-oai]

Summary

Move append-derived thread metadata projection off the synchronous rollout append path while preserving explicit visibility barriers.

• Coalesce metadata updates in a per-thread worker with generation barriers.
• Preserve retry, error propagation, shutdown, discard, and trace-parent semantics.
• Add a stronger append-and-flush API for goal-first threads that must be immediately listable.
• Keep normal turn-path appends asynchronous.

This is the thread-store slice split out of #30632.

Measured effect

In the non-ephemeral marker trace, the normal append caller returned in 3.485 ms while 112.632 ms and 133.694 ms of append-derived projection continued asynchronously.
Explicit durability barriers remain visible and unchanged where immediate persistence is required.

Validation

• CI is green at the current head.
• Twenty-five consecutive full parallel codex-thread-store package runs passed all 96 tests after stabilizing the scoped tracing assertion.
• Two later stress runs still passed the trace-parent assertion but hit unrelated SQLite disk-I/O failures when the machine had only 165 MiB free.
• just test -p codex-app-server goal_first_live_thread_appears_in_state_db_thread_list passed after one automatic retry caused by an initialization deadline.
• just fmt passed, with an unrelated justfile rewrite discarded.
• just bazel-lock-update completed without changing MODULE.bazel.lock.