Drop the SQLitePCLRaw.bundle_green dependency — provider choice should belong to consumers

[tomcurran]

First off — thanks for modernising this library; we've just migrated a production MAUI app from the abandoned TwinCoders 2.1.0 packages to SQLiteNetExtensions.Modern 3.1.0 and the switch went smoothly.

One packaging concern, though: the published 3.1.0 package hard-depends on SQLitePCLRaw.bundle_green 2.1.11, and I'd like to argue it shouldn't depend on any provider bundle at all.

From our restored dependency graph:

SQLiteNetExtensions.Modern/3.1.0 -> { SQLitePCLRaw.bundle_green: 2.1.11, sqlite-net-base: 1.11.272-beta }
SQLitePCLRaw.bundle_green/2.1.11 -> { SQLitePCLRaw.lib.e_sqlite3: 2.1.11, SQLitePCLRaw.provider.e_sqlite3: 2.1.11 }

Notably, #15 (merged into 3.1.0) intended to replace bundle_green with sqlitepclraw.config.e_sqlite3 — but the published 3.1.0 nuspec still declares bundle_green, so either that change didn't reach the packed nuspec or it regressed in a later dependency update.

Why a hard bundle dependency is a problem

1. It defeats the point of sqlite-net-base. The library correctly moved from sqlite-net-pcl to sqlite-net-base, whose entire purpose is to let the consumer choose their SQLitePCLRaw provider. Re-imposing bundle_green from the extensions layer takes that choice back away. The relationship extensions only need SQLitePCLRaw.core (which arrives via sqlite-net-base anyway) — they never touch a provider directly.

2. Duplicate SQLitePCLRaw.batteries_v2.dll. Consumers who bring their own bundle/config package (we pin SQLitePCLRaw.config.e_sqlite3 3.0.5 + SourceGear.sqlite3 so the app statically links a current SQLite on iOS) end up with two same-named batteries assemblies in the graph. The build silently resolves the conflict by assembly version — it happens to pick the right one for us today, but that's fragile and invisible to most consumers.

3. Security-audit noise no consumer can fix. bundle_green 2.1.11 pulls SQLitePCLRaw.lib.e_sqlite3 2.1.11, which is flagged by GHSA-2m69-gcr7-jv3q (CVE-2025-6965, bundled SQLite < 3.50.2) with no patched 2.x version available. Every consumer of 3.1.0 gets NU1903 warnings on every restore — which breaks CI pipelines running with NuGet audit gates or warnings-as-errors — even when (as in our app) the vulnerable native never ships in the output.

4. Surprising default on iOS. bundle_green on iOS means the Apple-OS-provided SQLite (provider.sqlite3) — an old, OS-controlled SQLite most apps don't intend to use. And when the consumer overrides the provider, the unused SQLitePCLRaw.provider.sqlite3.dll still ships in the app bundle as dead weight.

Proposal

Remove the provider/bundle dependency from the package entirely and let sqlite-net-base bring in SQLitePCLRaw.core alone:

• The nuspec/csproj for the published package depends only on sqlite-net-base.
• Samples/tests keep whatever bundle they need (that's the right place for bundle_green or config.e_sqlite3).
• The README gains a short "choose your provider" section: e.g. SQLitePCLRaw.bundle_e_sqlite3 for the common case, config.e_sqlite3 + SourceGear.sqlite3 for a current statically-linked SQLite, bundle_green if OS SQLite on Apple platforms is genuinely wanted.

This also resolves #16 at the root — the advisory disappears from consumers' graphs instead of needing workarounds.