Clarify production invocation, Android Auto support, and Android 16 fallback in AppFunctions docs

We tested the public AppFunctions sample locally with ADB and the AppFunctions Testing Agent. The sample works for flows such as searchContacts and sendMessage.

The main gap is not the local API usage. The unclear part is the production model for real apps.

Questions / doc gaps:

- Can Gemini invoke third-party AppFunctions in production, or is EAP/allowlisting required?
- If EAP/allowlisting is required, is there a public timeline or application path?
- What should apps use below Android 16, since AppFunctions is Android 16+?
- Are Android Auto / projected voice flows supported?
- Is AppFunctions intended to support business/domain-specific workflows, not only messaging/contact examples?
- How should apps think about migration from existing App Actions flows such as CREATE_MESSAGE?

Use case:
An enterprise field service app may need voice commands such as next activity, activity summary, route/navigation, customer calling, and customer messaging. The local sample proves the function-call model, but the documentation does not make the production access path clear enough to plan implementation.

Request:
Please add documentation that clearly explains the production caller model, Gemini access requirements, Android version fallback, Android Auto support, and relationship to existing App Actions documentation.
To use this in production gemini access is required and Gemini is giving access to limited app why should we have to spent time on this

Start with the public AppFunctions sample and its ADB/AppFunctions Testing Agent flows, then compare the existing App Actions documentation. Document the production caller and Gemini access model, Android version fallback, Android Auto support, supported workflow scope, and migration relationship so an enterprise app can determine whether its planned voice flows are viable.

Written by the indexing model from the issue text.