chore: set version to 0.9.5-rc5

[obasilakis]

Bumps VERSION from 0.9.5-rc4 to 0.9.5-rc5 so the v0.9.5-rc5 tag can be cut off dev.

It also points scripts/deploy/trinity-do-create.sh's default TRINITY_IMAGE_TAG at v0.9.5-rc5, which test_2380_installer_release_pin ties to VERSION.

Split out of #2862 per review finding I1 there, the same way #2838 carried rc4.

Why rc5

A droplet created from the v0.9.5-rc4 Marketplace snapshot never serves. First boot runs start.sh under umask 077, the rendered Caddyfile comes out 0600 root, the caddy service user cannot read it, and provisioning stops before Trinity starts. The fix is in #2862. rc4 cannot be submitted, so rc5 is the candidate for the DigitalOcean Marketplace submission.

Merge order

Merge after both #2861 and #2862.

• fix(onboarding, deploy): checklist updates without a reload; 1-Click first boot serves again #2862 carries the Caddyfile fix; without it, rc5 is rc4 again.
• fix(tests): evict the whole git_service package family — 13 leaked failures in test_ent615 (0.9.5 M1) #2861 fixes the 13 leaked test_ent615 failures that make backend-unit-test red on dev. The run on 3a47f7440 reports 13 failed, 16507 passed. The tag must be cut off a green dev.

Between this merge and the tag push, dev's installer defaults to an image tag that is not published yet. That window exists for every RC (#2838 had it too), and TRINITY_IMAGE_TAG overrides it.

This is release-candidate mode: no dev → main merge, no Closes block, no issue sweep, no release notes. The tag closes nothing and moves no branch.

Test plan

• pytest tests/unit/test_2380_*.py (installer release pin)
• After merge: tag v0.9.5-rc5, confirm publish-images.yml publishes all five images and latest does not move
• Packer build from v0.9.5-rc5, boot a droplet, and QA it before submitting

🤖 Generated with Claude Code

[dolho]

Review — approve, with merge-order as the only gate

Diff verified. Two lines, same shape as #2838 (rc4): VERSION 0.9.5-rc4 → 0.9.5-rc5 and the trinity-do-create.sh default TRINITY_IMAGE_TAG moved in lockstep. Ran test_2380_installer_release_pin + test_2380_installer_portability on the branch: 18 passed. No other rc4 pin exists in the tree — the remaining 0.9.5-rcN strings are docs/examples/learnings and packer/trinity.pkr.hcl's image_tag has no default (validation refuses latest), so nothing else needs to move.

Narrative verified. #2862 does add chmod 0644 /etc/caddy/Caddyfile.new + a umask 077 regression test — so the "rc4 boots to a Caddy that can't read its config" story is real, and rc5 without #2862 is indeed rc4 again. No file overlap with #2861 or #2862, so no rebase needed.

One request before merging: please do NOT enable auto-merge on this one (it's off now — keep it that way). The merge order in the description is load-bearing and nothing in CI enforces it: if this lands before #2862, dev says rc5 while the Caddyfile bug is still in start.sh, and a tag cut off that state ships the same broken snapshot under a new number. Merge #2861 → #2862 → this, then tag.

Minor, no action: CI is green on this branch today only because the 13 test_ent615 leaks that #2861 fixes are order-dependent; the base/head regression diff hides them. Not this PR's problem, just noting the "tag off a green dev" line in the description depends on #2861 actually landing first, not on this PR's checks.

🤖 Generated with Claude Code

[obasilakis]

Superseded: the bump is back in #2862, and the merge order (#2861, then #2862) makes the split unnecessary.