Check Cargo.lock into version control? #64

Right now Cargo.lock is gitignored, so CI resolves fresh on every run. Hit a case where that bit us:

datafusion-federation = "0.5.5" is a caret req, so a fresh resolve grabbed 0.5.6, which wants datafusion = "55" while we're on 54. Cargo happily built both trees and datafusion-flight-sql-table-provider stopped compiling. Nothing in the repo changed, just an upstream release. #62 works around it with =0.5.5, #63 does the real 55 bump.

So — worth checking the lockfile in? Would make CI reproducible, and it doesn't affect downstream consumers either way, only Cargo.toml does that.

Flip side: it'd also hide upstream drift, so we'd stop catching this kind of thing from normal CI. A scheduled unlocked run would cover that.

No strong opinion either way, just curious what folks prefer. If we do it, CI should probably pass --locked.