A test project with two Android clients

The two-APK case had no fixture: it was verified against a scratch project
that was not kept, so the shape three recent bugs came out of was covered
only by a tempfile unit test. test-projects/two-clients is two Apk
components in one checkout, each with its own cwd and its own package --
what tdep-survey looks like, and what service-and-app cannot stand in for,
since only one of its two components produces an APK.

tablet is slow on purpose (six seconds of pretending to cross-compile,
reporting its own progress) beside a phone that builds in two, because that
is what makes ?component= visible rather than merely asserted: building one
finishes while the other has not started.

Verified live against a throwaway server rather than reasoned about.
build?component=phone ran phone alone; afterwards phone reported built and
tablet did not, which is the sibling-masking bug -- under the root-anchored
"never built at all" check the tablet would have read as current and been
refused its own first build. prepare?component=tablet then ran tablet
alone and it did build. Each component resolved its own APK under its own
directory, with its own size and mtime, so nothing reports the first
match for both.

Also corrects a sentence in that README that went stale when discovery
moved per-component: find_apks is anchored at project.join(cwd), not at
the project path. The conclusion it supports is unchanged -- every other
fixture declares no cwd, so the anchor is still the project root for them,
and building into app/ is still what keeps a stub APK from being offered
as a build of Dev Updater itself. Re-ran the check command in that section:
only the updater's own APK is reachable from the repository root.

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

test-projects/README.md

@@ -28,10 +28,12 @@ anything the scan does not reach.
 
 ## The `app/` directory each one builds into
 
-`find_apks` matches APKs up to **two** directories below a project root, and
-it is run against the *project* path, not a component's `cwd`. A test
-project building into `test-projects/<name>/build/outputs/apk/` would
-therefore also be found from the repository root -- offered as a build of
+`find_apks` matches APKs up to **two** directories below where it is
+anchored, and it is anchored at a component's own directory --
+`project.join(cwd)`, which is the project path itself for a component
+declaring no `cwd`, as all of these do except `two-clients`. A test project
+building into `test-projects/<name>/build/outputs/apk/` would therefore also
+be found from the repository root -- offered as a build of
 Dev Updater itself, and, being the newest, served as the default. Somebody
 pressing Update on the Dev Updater card would get a stub app.
 
@@ -57,8 +59,9 @@ appear.
 | `two-variants` | Builds `debug` and `release`, so the phone gets a variant picker and `resolve_apk` has something to fall back from. |
 | `breakable` | `touch breakable/break-the-build` and its next build fails, in colour, on stderr. `rm` it and it stops. |
 | `service-and-app` | A `Server` beside an `Apk`: two components building at once, the whole service contract, a runtime log that is not this server's own, and a `resources:` declaration giving Uninstall real paths. |
+| `two-clients` | Two `Apk` components in one checkout, each with its own `cwd` and package. The only fixture where *two* components produce an APK, which is what per-component discovery, the per-component "never built at all" check, and `?component=` all need to be exercised against. `tablet` is slow on purpose so that building one rather than both is visible. |
 
-All four are unaccepted when first added, so each is also a run through the
+All five are unaccepted when first added, so each is also a run through the
 acceptance gate.
 
 ## The apps themselves