feat: automate fork releases and upstream merges - #6

Problem

Keeping a fork of T3 Code in sync with upstream and cutting fork releases was entirely manual: releases were tagged by hand, upstream merges were done ad hoc with no deterministic path, and update surfaces in the app did not understand fork-specific release channels, so fork users had no reliable way to know when their fork build was behind.

Implementation

• Tag-based release workflow for the fork, so releases are cut and published from tags rather than by hand.
• Deterministic upstream sync: merges follow a fixed, repeatable process instead of ad hoc pulls, making conflicts and drift visible early.
• Fork-first update precedence: update checks prefer the fork's own release channel over upstream so fork builds surface fork releases correctly.
• Direct merge threads: upstream merges can be driven as dedicated threads end to end, not just as manual git operations.

Verification

• 63 focused tests covering the new sync and release logic.
• 4 browser tests and 60 composer tests exercising the UI paths.
• Real component evidence captured from the running app (screenshots below).
• Format, lint, and typechecks pass on the touched packages.
• Real artifact verification against an actual built release, not just mocks.
• Standards/voice review of docs and user-facing copy.
• K3.1 Pro review pass on the full diff.

Known limitations

• check:changed cannot run end to end on Windows due to the vp-spawn limitation; the individual format/lint/typecheck steps were run directly instead.
• The Codex CLI limitation was encountered only during the live merge-thread test and does not affect the shipped behavior.

Screenshots

Before

After (pending update)

After (current fork)

Sidebar

Work performed by Kimi K3.1 Pro and Kimi K3-256K via T3 Code/pi.