[ChristopherPHolder]

What

Closes #106.

finish used to retry the whole pipeline (write, post, upload the transcript, store), so a failure after the post posted the summary again. A restart in that window did the same.

• The post is stored straight away. New RecordingStore.recordSummaryPost stores the Slack channel and timestamp as soon as the post is in Slack, using the existing columns, so no migration.
  • summaryPost and unlinkedPosts only see finished recordings, so edits and the startup permalink linker leave a post alone while it's still finishing.
• finish runs in three steps:
  • Prepare (retried as before): wait for the clips, write the summary and action items.
  • Publish: post once and store the post. If a post is already stored, from an earlier attempt or before a restart, it edits that message instead, without uploading the transcript again.
  • Complete (retried as before): the permalink, finishRecording, the post update and any rewrite.
• Slack retries: chat.postMessage and completing a file upload are only retried when Slack answered that it did nothing (rate-limited or a 5xx). A timeout or dropped connection isn't retried, since the post may have gone through. Other calls keep their retries.
• Tests, all failing against the old code:
  • finishRecording failing after the post still gives one post, one upload and one history row;
  • a restart with a stored post edits it instead of posting;
  • a timed-out post or upload completion isn't retried;
  • a 503 on a post is retried.
• Docs: docs/architecture.md and docs/recording.md describe the retry rule and the stored post.

Trade-off: if posting times out, the summary isn't retried until the next restart picks up the unfinished recording. Retrying sooner could post it twice.

Checked

• pnpm vp run -r typecheck, pnpm vp run check and pnpm vp run -r test pass.
• effect-tsgo diagnostics reports nothing for the bot, both libs and the Worker.