fix(packaging): put the release recipes on v3's build

Neither packaging/arch/PKGBUILD nor the Homebrew formula had been run
since Phase 1, and both were still calling v2's CLI: `wails3 build`
takes -tags, -obfuscated and -garbleargs and nothing else, so
`-clean -trimpath -ldflags` fails at the flag parser. Both also
installed from build/bin/, which is v2's output path — v3 writes to
bin/, and build/ is tracked build assets now.

Three more things the tree needs that neither recipe had. The tasks
invoke `wails3` by bare name, so scripts/toolbin has to be on PATH or
the build dies at its first sub-task. `wails3 build` has no -ldflags at
all, and build:native computes BUILD_FLAGS in its own vars: so a CLI
variable cannot override it — LDFLAGS_EXTRA is appended inside the
production -ldflags string instead, on linux and darwin alike, empty by
default so make build-dev/build-prod are unchanged. And bundling is a
separate step from building: `task build` produces a bare binary on
both platforms, so the formula's macOS path runs `task package`.

The build assets were the scaffold's, not this app's. Info.plist named
CFBundleExecutable `yjref` and com.example.yjref, nfpm packaged
./bin/yjref, the .desktop template said "A yjref application" — an .app
built from that plist would not have launched. They generate from
build/config.yml, whose info block had never been filled from
wails.json either; `wails3 task common:update:build-assets` is the fix.
nfpm's homepage and license are not derived from it and are set by
hand, which is noted in place, and the refresh regenerates build/ios
and build/android, which this repo does not carry.

arch-package.yml's pacman list moves to webkitgtk-6.0/gtk4 to match the
PKGBUILD's depends(): makepkg installs nothing itself, so a mismatch
fails at link time rather than at check time.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm

packaging/homebrew/README.md

@@ -65,12 +65,15 @@ authenticated `brew install`) for brew to fetch the release tarball.
 
 - **License**: declared as `license :cannot_represent` (custom license). Replace
   with the correct SPDX identifier once the license is finalized.
-- **macOS vs Linux**: `wails build` produces a `YellowJacket.app` bundle on
-  macOS (installed under the Cellar with an `exec` shim in `bin`) and a bare
-  `yellowjacket` binary on Linux (installed to `bin`).
+- **macOS vs Linux**: under Wails v3 the bundling is a separate step from the
+  build. `wails3 task build` produces a bare `yellowjacket` binary in `bin/` on
+  both platforms; on macOS the formula runs `wails3 task package` instead, which
+  wraps that binary in a `yellowjacket.app` (installed under the Cellar with an
+  `exec` shim in `bin`).
 - **Linuxbrew**: building on Linux additionally needs the system WebKitGTK/GTK
-  stack (`webkit2gtk-4.1`, `gtk3`, `alsa-lib`) — OS packages, not Homebrew deps.
-  macOS needs only the Xcode Command Line Tools.
+  stack (`webkitgtk-6.0`, `gtk4`, `alsa-lib`) — OS packages, not Homebrew deps.
+  v2's `webkit2gtk-4.1`/`gtk3` is now only the `-tags gtk3` escape hatch. macOS
+  needs only the Xcode Command Line Tools.
 - **Cask alternative**: if you later ship prebuilt macOS `.dmg`/`.zip` artifacts,
   a Homebrew *cask* pointing at those installs faster than this source build.
   This formula is the source-build path.