Bring the phone's lock file back to the graph it actually restores

The android job's restore has never been reachable — the runner had no JDK and no SDK, so it failed
before it got there — and DodoSSH.Client.Android is deliberately outside DodoSSH.slnx, so the solution
restore that keeps the other fourteen lock files honest has never seen this one either. It went stale
for a whole release and nothing could say so.

Two things had drifted by the time the repaired job reached the step: MinVer, added to
Directory.Build.props for the desktop updater, and the ABI set, which grew when the -r android-arm64
pin came off the packaging step so that the nightly is installable on more than an arm64 handset.

--force-evaluate on this project alone, and the fourteen it references come back byte-identical: an
android-* RID is not a graph any of them has a package for. Checked rather than assumed, because this
is the same mechanism that once put win-x64 into the server's lock files and broke its image build.

docs/platform-flags.md records the lasting half, which is not this fix: any change to a shared props
file touches a lock file this repository cannot verify from a machine without the Android workload.

docs/platform-flags.md

@@ -546,6 +546,34 @@ whose checkout is discarded and does matter on a developer's machine, so the rel
 `git checkout -- '*packages.lock.json'` afterwards. `-p:RestorePackagesWithLockFile=false` is not an
 alternative: it fails NU1005 whenever a lock file already exists.
 
+**The Android head's lock file is outside the solution, so nothing checks it until the android job runs
+— and the android job was broken for an unrelated reason for the whole of the release that went stale.**
+`DodoSSH.Client.Android` is deliberately not in `DodoSSH.slnx` (it needs a workload the other two jobs
+have no reason to install), so `dotnet restore DodoSSH.slnx --locked-mode` — the gate that keeps every
+other lock file honest — has never seen it. Its only gate is the android job's own restore, and that job
+could not reach the restore step at all while the runner had no JDK and no SDK.
+
+The result: `MinVer` was added to `Directory.Build.props` for the desktop updater and reached fourteen
+lock files. The fifteenth was not restorable on a runner, so it silently kept a graph from three releases
+earlier, and the first thing the repaired job did was fail:
+
+```
+error NU1004: The project's runtime identifiers have changed from.
+Project's runtime identifiers: android-arm64;android-x64, lock file's runtime identifiers android-arm64.
+```
+
+Two changes at once, which is why the message names both: the missing `MinVer`, and an ABI set that grew
+when the `-r android-arm64` pin came off the packaging step. `--force-evaluate` on that project alone is
+the fix, and — unlike the `win-x64` case above — it is safe to commit: the RIDs land in the Android
+project's own lock file and the fourteen it references are rewritten byte-identically, because an
+`android-*` RID is not a graph any of them has a package for. Check that with `git status` rather than
+believing it; it is the same mechanism that broke the server's image build, and it happens to land
+harmlessly here rather than by design.
+
+The lasting hazard is the first paragraph and not the fix. Any change to a shared props file is a change
+to a lock file this repository cannot verify from a machine without the Android workload, and it will go
+on being noticed later than every other one.
+
 **A Docker `ARG` named `VERSION` silently sets MSBuild's `Version`.** An `ARG` is an environment variable
 for the rest of the stage, MSBuild reads environment variables as global properties, and MSBuild property
 names are case-insensitive — so `ARG VERSION` in a build stage sets `Version` for every project built in