[fortmarek]

Moves the x86_64 Linux jobs from GitHub-hosted runners to Tuist runners:

• CI: Linux, on a 4 vCPU / 8 GB runner (tuist-linux-4vcpu)
• Release: Create release, Desktop (x86_64-unknown-linux-gnu), Docker, on the default runner (tuist-linux, 2 vCPU / 8 GB)

The arm64 desktop build stays on ubuntu-22.04-arm, since Tuist runners are x86_64 only. Windows and macOS jobs are unchanged.

Other changes to the CI Linux job:

• deps and _build use Tuist cache volumes instead of actions/cache. Volumes are saved after successful runs on main, so _build stays current with the latest main instead of only being saved when mix.lock changes, and there's no cache upload at the end of the job. Pull requests, including from forks, start from the latest saved copy but never write to it. The bun cache is no longer cached: bun install took the same 6–7s with or without a volume.
• Failed tests are retried up to twice (test_retries: 2), so a flaky test doesn't fail the run. Tuist still records it as flaky.

Timings

The CI Linux job before and after, with tests run with --cover:

Step	Before: GitHub, main (cache missed)	This PR: Tuist 4 vCPU (empty volumes)	Expected after merge (warm volumes)
Set up job and checkout	1s	4s	4s
Install Erlang & Elixir	6s	7s	7s
Restore cache / attach volumes	1s	2s	2s
Check formatting (compiles dependencies when cold)	56s	26s	~1s
Check warnings	17s	6s	~3s
Run tests	47s	23s	23s
Bun install and asset checks	skipped (tests failed)	9s	9s
Job	134s (about 140s if it had passed)	82s	~50–55s

"Before" is this run on main, whose dependency cache missed. When GitHub's cache hits, the job takes about 56–87s. This PR's own run starts with empty volumes, because only runs on main save them. The "after merge" column is estimated from runs with warm volumes in a fork. Job times are measured from when the job starts on a runner, so they don't include waiting for one. Retries added no time when tests passed, and in one run turned a flaky failure (session_live_test.exs:2825) into a pass after a 1.3s retry.

The release jobs only run on tags, the nightly schedule and workflow_dispatch in livebook-dev/livebook, so this PR can't exercise them. After merging, a manual workflow_dispatch of the Release workflow (which builds as nightly) would confirm them before the next tagged release.

🤖 Generated with Claude Code