test: wait for the snackbar instead of assuming one looper round

[almothafar]

Addresses #343. Deliberately does not close it — see below.

The three snackbar assertions in GaugeThemeToggleTest looked the bar up immediately after a single idle(). SnackbarManager shows one bar at a time and hands them to BaseTransientBottomBar.showView — the call that actually attaches the view being looked up — through the main looper, so the number of rounds between show() and the view existing is not a constant a test gets to assume. They now wait for the view, bounded to 20 × 25 ms (well inside the bar's 7 s life), and report what they were waiting for if it never arrives.

What I could not do

Reproduce it. CI saw the null once. Since then: 15 runs of the class alone, 6 runs of the whole suite, the release variant as well as debug, and a constructed case with monitoringStopped set so a second bar queues behind the first and forces the manager's hand-off. All green, every time.

So the mechanism is unknown, and the issue text's guess — that it waits on a layout pass — is wrong: Material's bytecode shows showView() attaches the view and only defers visibility until layout, and findViewById finds invisible views. I have corrected that on the issue.

This change cannot be worse than what it replaces, and it turns a bare "expected not null" into a bounded wait that names its subject. But it is a mitigation, not a fix, and calling it one would be claiming a guard I never watched fail.

Also recorded: something that did not work

An @After draining the looper, to clear any bar left current in the manager, seemed like sensible insurance. It ran the activity recreate that the tap tests leave queued on purpose, against an activity the try-with-resources had already destroyed, and failed two tests with "Cannot recreate activity since it's destroyed already". Reverted, and written next to the @After so the idea is not had twice.

Verified

733 tests green on both the debug and release variants (CI runs ./gradlew test, which is both — worth knowing, since running only testDebugUnitTest locally covers half of what CI does). Lint clean.

From review

Mutation-checked, and it changed what this PR claims. Setting AWAIT_ROUNDS to zero kills exactly one assertion: the post-rotation wait in theOfferSurvivesARotationInsideItsWindow. So that is the only site where the bar genuinely needs looper rounds to arrive — at the other three it is already attached when the assertion runs, and the wait is insurance rather than a guard. That is now said in the code instead of implied.

All four keep the wait anyway. The sites differ only by whether an activity was recreated first, and which of those needs waiting is not a property a reader should have to re-derive.

Corrected an overstatement of my own. The helper's JavaDoc said "more than twenty local runs of the class alone". It was fifteen of the class and six of the whole suite. That paragraph is gone rather than fixed — run counts rot, and they belong here, not in the source.

One review finding I did not take. The Spec axis argued the change sits on nondeterministic ground that no bound can fix: that SnackbarManager.cancelSnackbarLocked returns false without clearing currentSnackbar when its WeakReference has been collected, wedging the queue after a GC. The first half is right — I disassembled it. The conclusion is backwards. In show(), that false is what takes the branch to currentSnackbar = null; showNextSnackbarLocked(), so a collected reference is the recovery path, not a wedge. The wedge case would be a live callback, which resolves through the looper — exactly what a bounded wait absorbs.