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/arch/PKGBUILD

@@ -46,17 +46,30 @@ build() {
   local commit
   commit="$(git rev-parse --short HEAD)"
 
-  # `go tool wails/sqlc/templ` resolve from the tool directives in go.mod, so no
-  # extra CLIs are needed. Wails runs the frontend install+build itself.
+  # `go tool wails3/sqlc/templ` resolve from the tool directives in go.mod, so
+  # no extra CLIs are needed. Wails runs the frontend install+build itself.
+  #
+  # v3's build is a Taskfile tree, and the tasks in it invoke `wails3` by bare
+  # name — so the vendored tool has to be on PATH under that name or the build
+  # dies at its first sub-task with "wails3: command not found". scripts/toolbin
+  # is the shim the Makefile uses for the same reason; see the header there.
+  export PATH="$srcdir/$pkgname/scripts/toolbin:$PATH"
+
+  # `wails3 build` has no -ldflags flag of its own (that was v2), so the version
+  # stamp goes through the LDFLAGS_EXTRA task variable this repo added to
+  # build/linux/Taskfile.yml. -trimpath and -w -s are already in the production
+  # task's own flags, which is where -clean's frontend rebuild went too.
   go generate ./...
-  go tool wails3 build -clean -trimpath \
-    -ldflags "-s -w -X 'main.version=v$pkgver' -X 'main.commit=$commit'"
+  go tool wails3 task build \
+    LDFLAGS_EXTRA="-X 'main.version=v$pkgver' -X 'main.commit=$commit'"
 }
 
 package() {
   cd "$srcdir/$pkgname"
 
-  install -Dm755 build/bin/yellowjacket "$pkgdir/usr/bin/yellowjacket"
+  # v3 writes to bin/, not v2's build/bin/ — build/ is tracked build *assets*
+  # now (build/config.yml, the icon, the platform Taskfiles).
+  install -Dm755 bin/yellowjacket "$pkgdir/usr/bin/yellowjacket"
   install -Dm644 "$srcdir/yellowjacket.desktop" \
     "$pkgdir/usr/share/applications/yellowjacket.desktop"