Add FreeBSD remote_server CI job

[G36maid]

Summary

Add FreeBSD remote_server cross-compilation to the CI pipeline. This extends the existing xtask workflow generation system with a bundle_freebsd_x86_64 job that runs on a Linux Ubuntu 20.04 runner and uses cargo-zigbuild with a FreeBSD 15.0 sysroot to produce zed-remote-server-freebsd-x86_64.gz.

This PR is a companion to #55388 which adds the source-level FreeBSD support. Together they enable building and shipping the FreeBSD remote server binary.

What changed

xtask (Rust source):

• Added Platform::Freebsd variant to the Platform enum
• Added REMOTE_SERVER_FREEBSD_X86_64 asset constant and updated assets::all()
• Added Platform::Freebsd handling in steps.rs (cargo config, sccache, etc.)
• Added bundle_freebsd() function in run_bundling.rs that:
  1. Installs the x86_64-unknown-freebsd Rust target
  2. Installs ziglang and cargo-zigbuild via pip
  3. Downloads and caches the FreeBSD 15.0 sysroot
  4. Cross-compiles remote_server with appropriate CFLAGS/RUSTFLAGS
  5. Gzips and uploads the artifact
• Extended ReleaseBundleJobs with freebsd_x86_64 field in release and nightly workflows

CI workflows (auto-generated YAML):

• Rebuilt all workflows via cargo xtask workflows
• release.yml, release_nightly.yml, and run_bundling.yml now include bundle_freebsd_x86_64
• The FreeBSD remote server artifact is included in release asset validation and nightly uploads

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• N/A

[MrSubidubi]

The comment from @\maxdeviant above is happening because the function_name within the xtask workflow generation is a hack to get the names working which obviously does not work well on your machine, happy to harden that as part of this. In any case, these would definitely have to be removed, but just as a pointer of where to look for that.

Aside from this, please remove the crash handler stuff from this too, so this is easier to review on its own

[G36maid]

The comment from @\maxdeviant above is happening because the function_name within the xtask workflow generation is a hack to get the names working which obviously does not work well on your machine, happy to harden that as part of this. In any case, these would definitely have to be removed, but just as a pointer of where to look for that.

Aside from this, please remove the crash handler stuff from this too, so this is easier to review on its own

Thanks for the quick review! I'm still working on this PR.

[G36maid]

@maxdeviant @MrSubidubi
I've finished the cleanup and removed the crash handler changes.

It seems my local machine had some weird configuration. I've re-generated the workflow files and they are correct now.

[MrSubidubi]

Awesome! I'll take it from here and wait for Conrad to merge the other PR, but overall looks good so far.

One comment: I think we might need to look into not making this a blocker for releases - while I sincerely appreciate your efforts here, this might put us in a spot where we error due to a change in the source and notice on relese day, but would be unable to fix this ourselves in a timely manner. Curious on your opinion on this, but that's a concern I currently have at least.

[G36maid]

Maybe we can set it continue-on-error or Nightly-only?

[MrSubidubi]

I think continue-on-error might be a good start, we also do some release asset validation though where we should probably exclude it. Not entirely sure I get what you mean by "Nightly-only"?