fix: bind symbols via @Native, restore Flutter compatibility (0.4.1)

[jwinarske]

Two fixes, both surfaced by actually smoke-testing the Flutter example. 0.4.1.

1. Published 0.4.0 is unusable from Flutter

hooks >=2.1.0 depends on meta ^1.19.0
flutter_test from sdk depends on meta 1.18.0
→ version solving failed

Every Flutter app depends on flutter_test, so no Flutter project on an SDK pinning meta 1.18.0 (3.44.x) can depend on appstream_dart 0.4.0 at all. The bundled example is one of them — that is how this was found. CI missed it because its Flutter job runs 3.47.0.

Widening to hooks: '>=1.0.2 <3.0.0' and code_assets: '>=1.0.0 <2.0.0' fixes it. Verified resolution in both directions:

Context	hooks	code_assets	meta
standalone dart pub get	2.1.0	1.2.1	1.19.0
example under Flutter 3.44.2	1.0.2	1.0.0	1.18.0

The build hook is source-compatible with both majors, and pana still scores 160/160 — a standalone resolve still picks the latest, which is what that check measures.

2. The code asset was built and never used

hook/build.dart published libappstream.so as a code asset, but the VM consults its asset table only for @Native declarations — a plain DynamicLibrary.open(name) never sees it. So bindings.dart compensated with a seven-step runtime search. Comments in hook/build.dart and lib/src/appstream_native.dart claimed @Native was already in use; it was not.

Symbols are now @Native externals bound to @DefaultAsset, and the search chain is deleted (~180 lines): a /proc/self/maps scan, a glob through .dart_tool/hooks_runner/ internals, and candidates derived from Platform.script, the executable, and the CWD.

Security note: those CWD-relative candidates meant the process would load libappstream.so from ./lib, ./build, or ./src/build. Running an application from a directory an attacker can write to was enough to get a library of their choosing loaded. Removing them closes that.

The public API is unchanged — AppstreamBindings lives in lib/src/, is not exported, and appears only as a local inside a private function.

Verification

Exercised on three runtimes against the real 48 MB Flathub catalog, not just unit tests:

• dart run / dart test — 45/45
• Flutter example under GTK on wayland-0 — full import, 4677 components, 319 languages
• Same example on ivi-homescreen on wayland-0 — same result

Resolution goes through NativeAssetsManifest.json, which maps the asset to the plain soname libappstream.so, so the final dlopen uses the system loader. GTK works via the runner's RPATH=$ORIGIN/lib; embedders whose binary sits outside the bundle need it on LD_LIBRARY_PATH. The README now documents this, including that flutter build bundle does not do Linux native-asset packaging — use flutter build linux.

Performance is unchanged, measured rather than assumed:

Bindings	Run 1	Run 2
@Native	416 ms	411 ms
DynamicLibrary.lookupFunction	414 ms	409 ms

Expected: the FFI boundary is crossed twice per parse, and components stream back over the Dart port via Dart_PostCObject_DL, so the binding mechanism cannot move throughput. Argument passing, port protocol, and SQLITE_TRANSIENT handling are byte-identical.

clang-tidy clean, clang-format applied last, 149/149 C++ tests, dart analyze --fatal-infos clean, dart pub publish --dry-run 0 warnings.

Relationship to open PRs

Independent of #12 and #13 (disjoint files); merges in any order.