[sabinem]

Load test data into the new dev and staging instances

Hackagon now runs two test instances in one cluster: dev (hackagon-dev.sck-sit-dev.dscompute.ch) follows main, and staging (hackagon-staging.sck-sit-dev.dscompute.ch) runs the latest release. Whoever looks after them wants both filled with the standard test data, so they can try the app with realistic hackathons and users. They now run just cluster::reseed dev or just cluster::reseed staging.

Before this change, the cluster tooling knew only one dev instance, in a namespace and at a domain that no longer exist. The new dev URL was refused, and there was no way to aim at staging. Seeding staging properly would also have needed the release branch checked out. But the recipes come from the checkout, and the release branch's recipes predate staging.

What changed

• The cluster recipes take dev or staging instead of a kube context. Any other name, prod included, is refused. Each recipe also checks that the namespace's ingress serves that instance's host, and confirming a wipe means typing the namespace back.
• kubectl uses the kubeconfig at ~/.config/kube/sck-sit-dev, which HACKAGON_KUBECONFIG overrides.
• reseed builds the seed in a temporary git worktree, from the code the instance serves: origin/main for dev, the newest origin/release/* branch for staging. It no longer matters what you have checked out, so staging can be reseeded from main.
• Backups are now named hackagon--.sql.
• RELEASING.md, CLAUDE.md, the seed README and the backend-seeding skill now describe three instances.

Deliberately left out

• No changelog entry: nobody using the platform sees this change.
• The old hackagon namespace is no longer supported; it's expected to be removed.
• reseed staging builds from the release branch's latest commit, not from the release tag staging actually runs. If a hotfix is merged but not yet released, the seed comes from slightly newer code than staging serves.
• The docs say staging is installed by the same GitOps setup and picks up each new release, but don't say how.

[marftn]

Looks good! I only have a suggestion about the Deployment section. If you prefer to handle this in another PR, you can make a ticket and merge as is.

[marftn]

As in #400, I'm wondering whether a deployment section really makes sense in this file. I find the mix of public-facing docs and internal details (cloud-infra) a bit strange. I think we should be careful to separate audiences in our docs. I suggest moving these sections to a docs/operations or docs/internal/operations folder in this repo.

If you prefer to make a ticket and do it in another PR it's fine for me. Or if you have other suggestions.

[sabinem]

@marftn As this repo is public. I think we should remove the internals overall and not just move them to another folder. But that would also mean to move the cluster reseeding there. I did minimal changes now and will make a ticket to revisit this topic and solve it in a better more consistent way.