fix: cap dartastic_opentelemetry_api below 1.0.0-rc.4

[stephane-segning]

Summary

dartastic_opentelemetry_api 1.0.0-rc.4 (published 2026-10-08) breaks dartastic_opentelemetry 1.1.0-beta.15, and a fresh pub get of this package resolves exactly that pair. This caps the API dependency at >=1.0.0-rc.3 <1.0.0-rc.4, the same range the upstream beta.16 declares for itself.

Intent

main is red for any fresh resolve. CI, the example and every consuming app resolve without a lockfile, because pubspec.lock is gitignored.

• Measured on a clean clone of main (a964853): pub get picks dartastic_opentelemetry 1.1.0-beta.15 with dartastic_opentelemetry_api 1.0.0-rc.4. 16 of 19 test files fail to load, with errors such as "The getter 'spanEvents' isn't defined for the type 'APISpan'".
• flutter analyze stays green on that pair, because it does not analyse a dependency's own sources.
• ^1.0.0-rc.3 does not keep rc.4 out. pub selects the API package first and takes the newest, rc.4. It then settles for beta.15, because beta.16 (capped below rc.4) is the one SDK release that cannot sit beside rc.4. So beta.16 existing does not fix a fresh resolve.
• Flagged by the vaam-apps coordinator after the same break in fespalier_otel (fixed there in v0.13.1 with the same cap).

The cap should be lifted when dartastic_opentelemetry ships a release built on rc.4. A comment in pubspec.yaml says so.

Verification

Run locally with Flutter 3.48.0-0.4.pre, the version ci.yml pins, after deleting both lockfiles:

• flutter pub get in the package and in example/: both resolve dartastic_opentelemetry 1.1.0-beta.16 with dartastic_opentelemetry_api 1.0.0-rc.3.
• dart format --output=none --set-exit-if-changed .: 39 files, 0 changed.
• flutter analyze: no issues.
• flutter test: 217 passed, 0 failed. The same suite fails to load 16 files on the rc.4 pair.

Not run locally: the Kotlin and Swift jobs of ci.yml. This change touches no native code.

Version effect: a fix: commit, so release-please proposes a patch on its own. If it merges before the v0.6.0 feature work it is folded into that release's Bug Fixes section.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XLy7TiPAxtVjPKEwQ9iwBa

---

Generated by Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[stephane-segning]

android crash harness (API 34) is red on this PR, and it is red on main too, for reasons unrelated to this change (a one-line constraint in pubspec.yaml). Everything else is green: analyze and test, Kotlin, Swift/iOS, Super-linter, Trivy, both conventional-commit checks, and the API 30 harness in full.

Attempt 1 (run 37850098355, job 113560596835). FAIL native: launch 2: expected exactly one "native" record, received [], in the first harness command. The platform did its part (SIGSEGV, tombstone written, am_crash ... Native crash), and the recovery process's start-up summary reports nothing recovered. This is the "recovered 0" timing flake that #36 recorded on API 34 (native launch 2, recovered 0, expected 1), which the harness no longer hides with a retry. It did not recur: the same command passed in full on attempt 2.

Attempt 2 (job 113566138900). kinds (jvm, native, anr) and upgrade passed, then 16 of the 20 --repeat iterations passed. In the 17th the emulator hung: detected a hanging thread 'QEMU2 main loop'. No response for 17858 ms, then 'QEMU2 CPU0 thread' for 27760 ms, then about 645 crashpad ptrace: No such process lines, and the next adb call failed with adb: device offline. The harness then threw (exit 255). The app under test is not involved.

main fails the same way. The scheduled crash-harness runs on main (a964853, unchanged) went red on 2026-10-02 and have been red since: Oct 2, 3, 4, 6, 7 and 8, API 34 only, API 30 green. I read the logs of Oct 2 (run 36991454100) and Oct 8 (run 37764117153): both show the same QEMU hang lines, the same crashpad noise and adb: device offline / error: closed, after 21 and 23 passing cases. I did not read the Oct 3, 4, 6 and 7 logs. The last green runs were Sep 30 and Oct 1.

No open PR or issue carries a fix, and a runner-side emulator hang is not something this PR can fix, so I'm leaving the test as it is (not skipped, not retried again) and merging on the strength of everything else. A follow-up on the API 34 job (shorter --repeat, emulator options or a pinned system image) is worth its own ticket.

---

Generated by Claude Code