dotfiles: add Android Studio, and a per-user Android SDK

dotfiles: add Android Studio, and a per-user Android SDK

Two new steps, both x64-only: Studio has no Windows ARM64 build, and the
SDK's Windows build tools are x86/x64.

AndroidStudio installs Google.AndroidStudio (machine-wide; its NSIS
installer elevates itself) only when Studio is missing. It updates itself
in the app, and the package is published with UpgradeBehavior: deny and
RequireExplicitUpgrade, so winget would never upgrade it anyway. What the
check prevents is the other case: a Studio installed some other way - as on
the x64 laptop, where winget lists it only as "ARP\Machine\X64\Android
Studio" - is one winget cannot match to the package, so `winget install`
would run the installer over it. setup-windows-current.ps1 answers.

AndroidSdk sets up %LOCALAPPDATA%\Android\Sdk (or ANDROID_HOME's), which
that laptop never had - Studio was installed, its first-run wizard never
run: the command-line tools, platform-tools, and the newest stable
platform and build-tools, read from Google's package index at run time.
It accepts the SDK licences (the plan row says so), sets ANDROID_HOME,
puts the command-line tools on the user PATH, and points JAVA_HOME at
Studio's bundled JDK for a command-line gradlew when there is none.

The command-line tools are not what they were, and the step is built
around what they are now:

  - From 23.0, sdkmanager is deprecated: sdkmanager.bat is a shim over the
    new Android CLI (android.exe), which on first use installs itself into
    %USERPROFILE%\.android - ~90 MB in bin\, and a cli\ folder with its own
    Java runtime and a spool of usage metrics it uploads. No opt-out was
    found. The step calls the CLI directly, with its own
    "platforms/android-37.2" paths, so cmd never gets to split the old
    "platforms;android-37.2" at its semicolon.

  - CLI 1.0.16406183 crashes on the way out of every `sdk` command,
    0xC0000409 in ucrtbase, on this Windows 10 - in a console or not -
    after finishing the work, while --version and info exit 0. So its exit
    code is not trusted: each package asked for must have its package.xml
    afterwards. A crash with everything in place is a note; anything
    missing is a failure.

  - The archive calls itself cmdline-tools;23.0, a fixed version the CLI
    will never "update", so the step bootstraps and refreshes the tools
    itself from the index's cmdline-tools;latest (SHA-1 checked), only when
    the index has a newer revision.

Windows PowerShell 5.1's progress bar made the 148 MB download take about
ten minutes and five minutes of CPU; with it off, a whole first install
took 58 s and an unchanged re-run 4 s. BinSkim's 100+ MB download gets the
same fix. The tools unpack under an 8-character temp directory, so the
unpack is never deeper than the SDK path itself against MAX_PATH, and the
old copy is renamed aside before the new one moves in, so a failed delete
cannot leave the SDK without tools.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>