release v0.7.1: arm64-static binary + per-module arch_support

Two additions on top of v0.7.0:

1. skeletonkey-arm64-static is now published alongside the existing
   x86_64-static binary. Built native-arm64 in Alpine via GitHub's
   ubuntu-24.04-arm runner pool (free for public repos as of 2024).
   install.sh auto-picks it based on 'uname -m'; SKELETONKEY_DYNAMIC=1
   fetches the dynamic build instead. Works on Raspberry Pi 4+, Apple
   Silicon Linux VMs, AWS Graviton, Oracle Ampere, Hetzner ARM, etc.

   .github/workflows/release.yml refactor: the previous single
   build-static-x86_64 job becomes a build-static matrix with two
   entries (x86_64-static on ubuntu-latest, arm64-static on
   ubuntu-24.04-arm). Both share the same Alpine container + build
   recipe.

2. .arch_support field on struct skeletonkey_module — honest per-module
   labeling of which architectures the exploit() body has been verified
   on. Three categories:

     'any' (4 modules): pwnkit, sudo_samedit, sudoedit_editor,
       pack2theroot. Purely userspace; arch-independent.

     'x86_64' (1 module): entrybleed. KPTI prefetchnta side-channel;
       x86-only by physics. Already source-gated (returns
       PRECOND_FAIL on non-x86_64).

     'x86_64+unverified-arm64' (26 modules): kernel exploitation
       code. The bug class is generic but the exploit primitives
       (msg_msg sprays, finisher chain, struct offsets) haven't been
       confirmed on arm64. detect() still works (just reads ctx->host);
       only the --exploit path is in question.

   --list now has an ARCH column (any / x64 / x64?) and the footer
   prints 'N arch-independent (any)'.
   --module-info prints 'arch support: <value>'.
   --scan --json adds 'arch_support' to each module record.

This is the honest 'arm64 works for detection on every module +
exploitation on 4 of them today; the rest await empirical arm64
sweep' framing — not pretending the kernel exploits already work
there, but not blocking the arm64 binary on that either. arm64
users get the full triage workflow + a handful of userspace exploits
out of the box, plus a clear roadmap for the rest.

Future work to promote modules from 'x86_64+unverified-arm64' to
'any': add an arm64 Vagrant box (generic/debian12-arm64 etc.) to
tools/verify-vm/ and run a verification sweep on Apple Silicon /
ARM Linux hardware.

core/module.h

@@ -119,6 +119,31 @@ struct skeletonkey_module {
      * core/cve_metadata.{h,c} — looked up by CVE id, refreshed via
      * tools/refresh-cve-metadata.py. */
     const char *opsec_notes;
+
+    /* Architecture support for the exploit() body. detect() works on
+     * any Linux arch (it just consults ctx->host); the question this
+     * field answers is: if this module says VULNERABLE, will the
+     * --exploit path actually fire on aarch64 / arm64? Values:
+     *
+     *   "any"            — userspace bug or arch-agnostic kernel
+     *                      primitive (pwnkit, sudo*, pack2theroot,
+     *                      dirty_pipe, dirty_cow, most netfilter/fs
+     *                      bugs that use msg_msg sprays + structural
+     *                      escapes).
+     *   "x86_64"         — strictly x86-only (entrybleed needs
+     *                      prefetchnta + KPTI, which doesn't apply
+     *                      to ARM's TTBR_EL0/EL1 model).
+     *   "x86_64+unverified-arm64" — exploit body likely works on
+     *                      arm64 but hasn't been verified on a real
+     *                      arm64 host yet (e.g. copy_fail_family
+     *                      assumes some x86_64 struct offsets;
+     *                      --full-chain finisher uses x86_64-style
+     *                      kernel ROP gadgets).
+     *
+     * NULL = unmapped (treat as "x86_64+unverified-arm64" by default;
+     * a future arm64-on-Vagrant sweep will fill these in). Surfaced
+     * in --list (ARCH column) and --module-info. */
+    const char *arch_support;
 };
 
 #endif /* SKELETONKEY_MODULE_H */