Add support for Haiku R1/beta6

[jacob-carlborg]

Builds and releases an R1/beta6 image alongside the R1/beta5 one.

Run the workflow for branches containing a slash

branches: '*' doesn't match a slash, so pushes to branches like
feature/foo never triggered the workflow. ** matches across path
separators. This commit (7e0bcd5) is independent of the rest and can be
cherry-picked if you'd rather land it on its own.

Build R1/beta6 from the official test build

R1/beta6 hasn't been officially released yet, so the ISO isn't on the release
mirrors. main.pkr.hcl gets an iso_urls variable that overrides where the
installation ISO is downloaded from, defaulting to the existing mirror list,
and var_files/r1beta6/x86-64.pkrvars.hcl points at the official test build,
hrev59866_53.

When the release is out, dropping iso_urls from that file and replacing the
checksum switches R1/beta6 over to the mirrors. Nothing else needs to change.

Notes

• The installer boot steps are unchanged. If the R1/beta6 Installer or
  DriveSetup flow shifted, that's where a hang would show up
• The ISO checksum is the published one for the test build. It couldn't be
  verified locally, since the Haiku mirrors are unreachable from the
  environment this was developed in, so the build is the first real check
• packer validate passes for both versions, and packer console confirms
  R1/beta6 resolves to the test build URL while R1/beta5 still resolves to
  the five mirrors

---

Generated by Claude Code

[jacob-carlborg]

CI status, and a blocker on the R1/beta5 job that isn't from this branch.

r1beta5 fails in pkgman refresh

Three runs now, over two days, all identical. The VM installs, SSH comes up, then:

+ pkgman refresh
*** failed! : I/O error
    Fetching repository checksum from https://eu.hpkg.haiku-os.org/haiku/r1beta5/x86_64/current ...
    Validating checksum for Haiku ...
    Activating repository cache for Haiku ...
    Fetching repository checksum from .../haikuports/r1beta5/x86_64/current ...
    Validating checksum for HaikuPorts ...

The Haiku repository fetches and activates fine; HaikuPorts fails right after the
checksum. Nothing on this branch touches provision.sh, var_files/r1beta5/ or
the R1/beta5 ISO source, and packer console confirms R1/beta5 still resolves to
the same five mirrors it always did.

I tried to confirm it against master by re-running the last green build on
master, but GitHub refuses to re-run it — it's from April, over the one month
limit.

The retry didn't help

5f15777 wraps the package downloads in a 5-attempt retry with backoff, on the
theory that a large transfer was being truncated. All five attempts failed the
same way, each in about five seconds, so this isn't a slow or flaky transfer —
the HaikuPorts repository fetch fails immediately and consistently from the
runners. I'll drop that commit rather than leave a retry that only makes
failures slower; I'm holding off until the in-flight R1/beta6 job finishes so I
don't spawn a third concurrent build of it.

Whether this is the beta5 HaikuPorts repository specifically or the package
servers generally, I can't tell from here — the environment I'm working in
can't reach hpkg.haiku-os.org at all. The R1/beta6 job hits the same
pkgman refresh, so if it gets through, the problem is specific to the beta5
repository, which would be worth reporting upstream.

This matters beyond this PR: while the R1/beta5 job is red, tagging v0.2.0
produces a release without the R1/beta5 image, which would 404 for everyone
already using version: r1beta5.

r1beta6

Still building at ~20 minutes, past the ~10 minutes a successful R1/beta5 build
takes. It may just be a slower ISO download from the CDN, or it may be stuck in
the installer boot steps. I'll report either way when it lands. Worth noting the
job has no timeout-minutes and Packer's ssh_timeout is 10000s, so a stuck
build sits there for nearly three hours before failing.

---

Generated by Claude Code

[jacob-carlborg]

Update on both versions.

R1/beta5: copied instead of built

Per the R1/beta5 package repositories being removed upstream, the R1/beta5
image is now copied from the v0.1.0 release rather than rebuilt, the same way
freebsd-builder handles the versions it can no longer build. The matrix entry
carries the release tag, Build Image is skipped for it, and everything
downstream is untouched, so the copied image still goes through Test Image and
still gets uploaded to the release. The disproved retry is reverted in the same
commit.

Worth being explicit: this freezes the R1/beta5 image. Any future change to what
goes inside it can't be applied, since it can't be rebuilt.

R1/beta6: the boot steps don't match the R1/beta6 installer

The build doesn't fail, it hangs. Packer types the whole boot command sequence,
then waits for a machine that never comes up:

[INFO] Attempting SSH connection to 127.0.0.1:3943...
[DEBUG] SSH handshake err: Timeout during SSH handshake

That repeated for 62 minutes before I cancelled it. The ISO downloads and
verifies against the checksum, so the test build itself is fine; what fails is
driving the installer. Packer types the boot steps blind, so the log can't say
which keystroke went astray — that needs eyes on the VM's screen.

Meanwhile the timeouts are bounded (2929892): ssh_timeout drops from
10000s to 15m, and the job gets timeout-minutes: 30. A stuck build now
fails in about 18 minutes instead of nearly three hours, which is the difference
between being able to iterate on the boot steps and not.

---

Generated by Claude Code

[Begasus]

Can't make heads nor tail from this claude code, but remember that r1beta5 is dropped for the repositories, you will have to switch repositories to r1beta6.

See: https://github.com/Begasus/haikuports/wiki/Updating-Haiku-or-switch-from-nightly-to-beta-or-visa-versa#switch-from-nightly-to-r1b6-this-works-on-32bit-and-64bit (this works the same for updating r1beta5 as it does for nightly to update to r1beta6.

[jacob-carlborg]

R1/beta6 is already in master.