fix(android): name the placeholder in a fill verification failure

[okwasniewski]

Summary

Refs #2903, #2634. Downstream report: Android fill verification failed on an onboarding field whose app rewrites its value, deterministic across reruns; the iOS cousin of the same test reported the placeholder (e.g. Merchant) as the observed value.

The Android verifier already samples the hierarchy for 1.5 s until the value holds, and already collapses hint-only text to the empty value when the helper reports hint-showing (#2063). What the failure did not do is say so: details.actual is the raw dump text, which on modern Android is the hint of an empty field, and neither the hint-showing fact nor the hint reached details.actualInput. A reader of the failure could not tell a placeholder from a typed value.

AndroidFillVerificationNode now carries hintShowing and placeholder (the helper's hint), so both targetInput and actualInput in the failure details name them. No verification rule changes; the candidate type that already held hintShowing privately now exposes it through the node.

Touched: 2 source files, 2 test files.

Validation

Tested commit d2201eb83.

• pnpm check:affected --run: passed.
• Tests: buildFillFailureDetails carries hintShowing: true and the placeholder on a hint-only mismatch; verifyAndroidFilledTextInHierarchy exposes hintShowing on the hint-only case and the helper hint on a typed value.
• Live, Pixel emulator (emulator-5554), CLI at this head with the built snapshot helper: Settings search, empty field reads hintShowing: true, placeholder: "Search settings"; after fill @e2 "Acme Ltd" the same node reads hintShowing: false with the placeholder retained. I could not provoke a live mismatch on Settings; the details shape is pinned by the unit tests.
• Not addressed: the value-rewriting collision itself (ios: fill's verified element route cannot recover from a field whose app writes its value back mid-burst #2903) is an engine behavior on the iOS runner side; this PR makes the Android failure legible.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cubic-dev-ai]

No issues found across 4 files

_{Re-trigger cubic}

[thymikee]

Reviewed at d2201eb, the code looks right. The change is additive typed-field plumbing in packages/platform-android and touches no CI-gate surfaces beyond the two changed test files. All 13 checks are green, and I'm not aware of any conflicts. Nothing in the code blocks it.

Not blocking, feel free to take or leave it: at the merge base, toFillDiagnosticNode already spread the whole node and the fill candidate already set hintShowing on it, so details.actualInput.hintShowing was already reaching failure details at runtime before this PR — the PR body's claim that this fact wasn't reaching actualInput should be corrected to say this PR types hintShowing and adds placeholder, and the new hintShowing assertions could be dropped or kept and labeled as type-level pins.

I couldn't verify the live-device run on the Pixel emulator (Settings search field) since no log or output was attached — can you share the run output showing hintShowing/placeholder populated on-device? I only traced the data path through ui-hierarchy.ts, fill-verification.ts, and fill-diagnostics.ts and checked packages/platform-android and src/daemon/src/commands for other consumers of actualInput/placeholder; is there a downstream reader elsewhere that benefits from these new fields today, or is that intentionally out of scope for this PR?