2 Commits (c25b7ccbdfa486b21409a0b7e40a7165cf8cdcf2)

Author	SHA1	Message	Date
Strycher	c25b7ccbdf	chore(#335): pin drift, commit pubspec.lock, guard the web asset version ... Owner asked whether the web assets must be re-downloaded on every drift bump. They do not - the version can be pinned - but doing that safely needed three changes, because the failure mode is silent. 1. drift and drift_flutter are pinned EXACTLY (2.34.2 / 0.3.1), no caret. The committed web assets are built for a specific drift release, so a caret would let pub resolve a newer drift than the shipped binaries and break the web build with no signal at compile time. 2. pubspec.lock is now committed (removed from .gitignore). It was ignored, which for an application means resolution can differ between machines and CI. That undermines the pin: the assets are matched against the RESOLVED version, so resolution has to be reproducible. Owner-authorized, and it is a repo-wide change rather than a storage-only one. 3. New test asserting the shipped assets match the resolved drift version, plus that both files exist and the wasm really starts with the WebAssembly magic bytes. Verified in both directions: it passes when matched and fails loudly with re-download instructions when skewed. Without (3) a stale asset compiles, deploys, and only fails in the user's browser - the exact silent-failure class SAFELANE 6 forbids and that produced #333 earlier. Upgrading drift is now a deliberate step: bump the pin, re-download both assets, update web/drift_assets.version. The test fails until you do. flutter analyze clean, tests pass.	1 day ago
Strycher	19858698ee	feat(#335): add drift and prove it opens on the targets buildable here ... Step 1 of #335, deliberately before any data migration: prove the store works before trusting it with message history. Adds drift + drift_flutter, a key/value StoredBlobs table mapping 1:1 onto the existing SharedPreferences keys, and verifyReadWrite() as a runtime probe. Key/value rather than relational tables on purpose: it maps directly onto the current store interfaces, so callers do not change and the migration can be verified row-for-row against the old keys. Relational schemas come later, once this is proven and querying is actually wanted. Verified here: - 3 tests pass, including a 6 MiB round-trip - larger than the 5 MiB localStorage cap that makes the web build impossible today - flutter analyze clean - Windows release build succeeds - Web release build compiles Two findings from the gate that a plan-on-paper would have missed: 1. sqlite3_flutter_libs 0.6.0+eol is a DEPRECATED no-op. From sqlite3 v3.x it is unnecessary and drift_flutter already covers it, so it is not a direct dependency here. 2. The web build COMPILES BUT WOULD FAIL AT RUNTIME: drift needs sqlite3.wasm and drift_worker.dart.js shipped in web/, and neither is present. Per drift docs they are downloaded from GitHub releases, version-matched to pubspec.lock (drift 2.34.2, sqlite3 3.5.0), and the server must serve .wasm as Content-Type: application/wasm. Not done here - downloading files needs explicit human approval. Also noted: the drift_dev CLI does not compile at these versions (allSchemaEntities missing from the drift3_preview GeneratedDatabase), so its asset tooling is unavailable. build_runner code generation is unaffected. No user data is touched. No store is switched over. The migration is the next step and remains gated on the web assets question.	1 day ago