Cleanup old mechanism to use server to connect to androidMobile agent

[jebrans]

Summary

Remove the legacy takeAction device-command path from the mobile-2
Android sample, making registerClientAgent the sole mechanism for
onboarding the app and dispatching device actions.

The sample previously carried two parallel command paths. The
client-hosted androidDevice agent receives typed executeAction
callbacks and returns a result to TypeAgent. The older path handled
fire-and-forget takeAction calls pushed by the server-side
androidMobile agent over the clientio: channel; it duplicated the
alarm and timer handlers but discarded the outcome, so TypeAgent never
learned whether the intent actually launched.

searchNearby existed only on the legacy path, so it moves into the
client-agent schema first. It now reports success or failure back like
the other two actions instead of being fired blind.

The clientio: channel is retained — it remains the only transport for
display and user-interaction traffic (appendDisplay, setDisplay,
setDisplayInfo, notify, requestChoice, requestInteraction).
Only the takeAction branch is removed.

Example

Before

Two paths reached the same Android intents, and only one could report a
result:

androidMobile agent -> takeAction("search-nearby", ...) -> Android intent
                                                        (result discarded)

androidDevice agent -> executeAction(setTimer) -> Android intent -> ActionResult

searchNearby was reachable only through the first path, so a failure
to launch the maps app was invisible to TypeAgent.

After

One path, and every action reports its outcome:

Android app -> registerClientAgent("androidDevice", inlineSchema)
            -> executeAction(setAlarm | setTimer | searchNearby)
            -> Android intent
            -> ActionResult

searchNearby can now be tested deterministically like the other
actions:

@action --parameters {"originalRequest":"coffee","searchTerm":"coffee shops"} androidDevice searchNearby

Searching nearby for coffee shops

A failed launch now surfaces as an action error rather than silence:

No maps app is available on this device.

Notes

Verified with testDebugUnitTest, assembleDebug and lintDebug —
79 tests, 0 failures, lint clean. Two tests were added covering
searchNearby parsing and its invalid-parameter path.