examples: pin jni to 1.0.0 (1.0.1 breaks aarch64 Linux builds)

[FeodorFitsner]

Unblocks CI. Test Bridge example on Linux ARM64 has been failing on every recent PR with 19 copies of:

global_jni_env.c:284:68: error: passing 'va_list' (aka '__builtin_va_list')
                                to parameter of incompatible type 'void *'

Root cause: upstream, not us

jni 1.0.1 was published 2026-07-27T01:10:21Z. Last green ARM64 run was Jul 25 22:23; first failure Jul 27 15:53.

	passing run (Jul 25)	failing run (Jul 27)
resolved	+ jni 1.0.0	+ jni 1.0.1
global_jni_env.c	never compiled	25 references, 19 errors
runner image	ubuntu-24.04-arm 20260719.67.1	identical
Flutter	.fvmrc 3.44.8	identical

1.0.1 added global_jni_env.c, which passes a va_list where a void * is expected. On x86_64 va_list is an array type that decays to a pointer, so it compiles; on aarch64 it's a struct, so it's a hard error. That's why only the ARM64 jobs fail — Android, Linux AMD64, Windows and the Apple jobs all pass.

Reported upstream: dart-lang/native#3498.

Why it surfaced on a release PR

The examples depend on the serious_python packages by path. Bumping their version invalidates the committed pubspec.lock, so pub re-resolves the whole graph and takes the newest transitive versions — picking up jni 1.0.1. Any PR touching package versions after Jul 27 01:10Z would have hit this, and every future release PR will until it's pinned.

jni itself arrives via path_provider → path_provider_android → jni_flutter → jni.

The fix

dependency_overrides:
  jni: 1.0.0

jni_flutter 1.0.1 declares jni: ^1.0.0, so 1.0.0 satisfies it — this narrows within the allowed range rather than overriding a real constraint.

Applied to all three examples. Only bridge_example runs in CI, but the other two break identically for anyone building them on an ARM64 Linux host. Verified each resolves to jni 1.0.0 after flutter pub get.

The flask_example / run_example locks also pick up the current path-dependency version (4.0.0 → 4.4.1) — they were simply stale.

Drop the override once a fixed jni ships.

Note for #242

That PR branched from the same commit, so it needs main merged in after this lands to go green.

This does not protect Flet users

packages/flet depends on path_provider: ^2.1.5, so a Flet app pulls jni through the same chain — and a generated Flet project has no committed lock, so it always resolves the newest. flet build linux on an ARM64 host will hit this. Fixing that needs a separate pin on the flet side, or the upstream fix.

[FeodorFitsner]

Folded into #242 as cdc1902 — no need for a separate branch. The pin ships with the 4.4.2 bump.