Verify generated web apps on ARM Linux and Windows

[crimson-knight]

What changed

• add a GitHub-hosted Linux ARM64 compile-and-smoke job
• add a GitHub-hosted Windows x86_64 compile job for the Amber CLI and a generated V2 web app
• add a PowerShell smoke script that generates the clean web scaffold, installs dependencies, runs its request spec, and compiles the application
• install the SQLite import library required by the CLI on Windows while preserving Crystal's bundled library path
• add linux-arm64 to the release matrix, artifact verification, and upload list
• document the CLI 2.0.3 ARM64 source-build path until that archive ships

Platform evidence

• Linux ARM64 passes against the released Amber 2.0.0-beta.2 dependency.
• A manual next-release workflow run built, smoke-tested, archived, checksummed, and uploaded the linux-arm64 artifact alongside the existing targets: https://github.com/amberframework/amber_cli/actions/runs/31489541964
• Windows reaches project generation, dependency installation, and request specs against beta.2, then fails because Amber's controller-relative ECR macro assumes Unix path separators.
• The Windows job pins the generated app to the exact candidate framework commit from Fix controller-relative ECR paths on Windows amber#1402. With that fix, the complete Windows job passes, including the native application compile.

Validation

• all pull-request checks pass, including Linux ARM64 and Windows x86_64 generated-app jobs
• Amber CLI test suite: 406 examples, 0 failures, 0 errors after building the required LSP test binary
• framework render-path regression spec: 7 examples, 0 failures
• full framework suite: 2,321 examples, 0 failures
• release workflow run: all three build targets passed; release-only upload jobs correctly skipped for the manual dispatch
• workflow YAML parsed locally and git diff --check passed

Windows is intentionally not a beta release gate. Its job should return to the released framework version pin after the fix ships in a new Amber beta.