Tags: expo/expo

[web][ai] Add the browser Prompt API provider

[android][template] Honor the configured Kotlin compiler version

[ncl][ai] Add ModelRequirements controls to the expo-ai demo screen

The demo screen could not set requirements, so there was no way to see a
device change its answer when one was asked for. A new Requirements section
builds one ModelRequirements object and feeds it to the availability check
and to preparation. Every other call on the screen is unchanged.

The section has a switch per requires capability, a presence switch for
provider, fields for input and output languages, and a report printing the
object exactly as it is sent. Unset controls are left out rather than sent
empty, so a trailing comma in the language field does not become an
ERR_OPTIONS_INVALID.

The feature list is derived from the package type rather than retyped, so a
capability added to expo-ai fails the build here instead of silently missing
a switch.

The copy states only what the source does. A required capability yields
reason unsupported-feature only when the provider has not already refused;
naming a language on Android yields language-support-unknown except where
the backend cannot run at all and answers unsupported-os-version first; and
the provider key is validated and nothing more, so its switch changes the
object without changing any answer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

[ai] Add the shared JavaScript API

Registers the package with bare-expo, the app the repo's native unit tests run
against. Without that dependency the package never reaches bare-expo's
node_modules, autolinking never sees it, and `et native-unit-tests` asks Gradle
for a `:expo-ai:` project that does not exist. The lockfile entry lands in the
same commit as the manifest so each PR in this stack satisfies
`pnpm install --frozen-lockfile` on its own.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

[ios][ai] Add the Apple Foundation Models provider

[android][ai] Add the Gemini Nano provider

[ai] Describe the Apple unavailability reasons

The reason map only covered the Android, web, and JavaScript codes, so every
Apple unavailability — unsupported-os, unsupported-device, intelligence-disabled,
and unsupported-language — fell through to "The provider did not report a
recognised cause." on iOS and macOS. Each of the four codes now has its own
explanation, including the iOS 26 and macOS 26 floor that Foundation Models
requires. The provider-side codes are unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>