Support a documented, native Intel macOS source-build path

### Before filing

- [x] I searched [open and closed issues](https://github.com/block/berd/issues?q=is%3Aissue) for duplicates.
- [x] I am using a recent [release](https://github.com/block/berd/releases) and this doesn't already exist.
- [x] This is one request, not several bundled together.

### Closest existing issue

none found

### Is this new, or an improvement?

New capability — Berd can't do this at all today

### The problem, in your terms

I use an Intel Mac and want to run Berd without Rosetta. The published macOS artifacts are Apple-silicon-only, so the only possible route is building from source. The public documentation gives the general `just setup` and `just dev` flow, but it does not say whether native Intel macOS is supported, identify an Intel-tested toolchain, or provide a way to verify that the app and all bundled sidecars are actually `x86_64`.

I attempted the current source build on macOS 15.7.7 / `x86_64`. Before native compilation, `just setup` picked up pnpm 11.19.0 from `PATH` even though `package.json` pins pnpm 10.33.0. pnpm then modified tracked `pnpm-workspace.yaml` and exited with `ERR_PNPM_IGNORED_BUILDS`. Routing pnpm through Corepack allowed the workspace and SDK steps to continue, but the managed Goose checkout is large and the validation was stopped during that clone. I therefore cannot tell whether Intel is intentionally supported, happens to work, or fails later in bundling.

### What you do today

There is no published Intel artifact I can install. My workaround is a manual source-build investigation: install the repository's pinned Rust toolchain, supply a native `just`, force the pinned pnpm through Corepack, keep the checkout clean, wait for the managed Goose build, and then inspect every Mach-O binary by hand. I stopped before the build completed because this still would not establish whether the path is supported or merely incidental.

### What you'd like to see

Please provide an explicit, reproducible native Intel macOS source-build path, if Intel remains within Berd's intended platform scope. At minimum:

1. State whether Intel macOS source builds are supported and retain the existing macOS 14.0 minimum.
2. Preflight the host architecture and the pinned Rust/pnpm prerequisites before setup mutates the checkout.
3. Document the exact commands for `just setup`, `just dev`, and `just bundle-macos` on `x86_64-apple-darwin`.
4. Verify the architecture of the Berd executable and bundled `goosed`, `berdctl`, and `catch` sidecars.
5. Add a maintainer-owned Intel validation lane or documented periodic test so support does not silently regress.

If Intel is intentionally unsupported, an explicit statement and an early, clear setup error would still resolve the ambiguity.

### Why this belongs in Berd itself

This cannot be implemented by a Berd skill, agent, extension, or automation. Host-target selection, dependency preflights, Tauri bundling, sidecar staging, and architecture/signing verification all live in Berd's build and packaging layer. A user-local extension only runs after a working app exists.

### Non-goals

- No Intel or universal release artifact is required by this request; a reliable source-build path is sufficient.
- No Rosetta-based workaround.
- No lowering `MACOSX_DEPLOYMENT_TARGET` below the current 14.0 default.
- No change to upstream signing, notarization, or release infrastructure.
- No broad refactor of Berd, Goose, or Catch.

### Alternatives you considered

- **Rosetta:** rejected because the goal is a native `x86_64` application and native sidecars.
- **A maintained fork:** possible, but it leaves one user responsible for tracking build-script and sidecar changes indefinitely.
- **Manual local patches and architecture inspection:** useful for investigation, but not a stable support contract.
- **Continue using pnpm 11:** it modified the tracked workspace configuration and failed before native compilation; forcing the repository-pinned pnpm is safer.

### Mockups, prior art, or other context

Source snapshot tested: `b621258f7f5d9c03e5130a1ea18f410caaeb1033` (2026-08-19).

Host/toolchain:

- macOS 15.7.7 (24G720), Intel `x86_64`
- Command Line Tools 16.4; Apple clang 17.0.0 targeting `x86_64-apple-darwin`
- Berd-pinned Rust 1.94.1, host `x86_64-apple-darwin`
- Node v24.1.0 (`x86_64`)
- repository pin pnpm 10.33.0; initially active pnpm 11.19.0
- just 1.58.0 (`x86_64`)
- jq 1.7.1

There are encouraging source-level signs but they are not proof of a working bundle: the managed Node code recognizes `x86_64-apple-darwin`; the Catch staging script maps that triple to an `x86_64` slice and ad-hoc signs it; and `build_darwin.sh` uses the native host while defaulting to `MACOSX_DEPLOYMENT_TARGET=14.0`.

Observed setup failure with pnpm 11:

```text
[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts:
@modelcontextprotocol/ext-apps@0.3.1, esbuild@0.28.2

Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.
error: recipe `_setup-dev-deps` failed on line 67 with exit code 1
```

The upstream checkout was returned to a clean state. I did not reach `just dev`, bundling, binary-architecture verification, signing checks, or launch testing, so this is a request for a supported validation path rather than a claim that the current Intel build definitively fails.

Read package.json, pnpm-workspace.yaml, build_darwin.sh, and the Catch staging script first, then trace the existing just setup, just dev, and just bundle-macos entry points. Run the pinned-toolchain setup on x86_64 and verify the Berd executable plus goosed, berdctl, and catch architectures. Done means a documented reproducible native path, or an explicit early unsupported error.

Written by the indexing model from the issue text.