Generate the Datastore data-plane library (google.datastore.v1)

The Datastore admin API already exists as a generated REST GAPIC (`google-cloud-datastore-admin-v1`, from #979 / #980), but the data-plane API (`google.datastore.v1`) isn't available yet — `Lookup`, `RunQuery`, `RunAggregationQuery`, `BeginTransaction`, `Commit`, `Rollback`, `AllocateIds`, `ReserveIds`. There's a reserved, empty scaffold at `src/datastore` (`google-cloud-datastore`, `skip_release: true`) from #1802, but nothing implemented and no issue tracking it. This is the same admin-first/data-plane-later path Firestore and Pub/Sub already went down, so I'd like to pick up the data-plane piece.

One thing that makes Datastore easier than the other data-planes: in #2655 the cases that needed a thick hand-crafted client to avoid incorrect results were Pub/Sub (leasing / exactly-once), Bigtable (chunk→row merging), Spanner (resume-token rewind), Storage (checksums / resumable uploads), and Firestore (bidi streaming). Datastore has none of that — it's 8 unary RPCs, no streaming, and full REST/JSON support at `datastore.googleapis.com`. So it fits the default REST/JSON-over-gRPC policy and can be a plain generated GAPIC, just like the admin crate.

My initial plan (not married to it) would be to add `google-cloud-datastore-v1` to `librarian.yaml` pointing at `google/datastore/v1`, generate it as a REST GAPIC into `src/generated/datastore/v1` with the same shape as `datastore-admin-v1`, wire it into the top-level `Cargo.toml` and CI, and leave the reserved `src/datastore` crate alone for now.

A few things I'd want your read on before writing any code:

- Would you rather this land as `google-cloud-datastore-v1` under `src/generated/datastore/v1`, or go into the reserved hand-crafted `src/datastore` crate (which could still use the HTTP transport — no gRPC needed since there's no streaming)?
- Is an idiomatic layer down the road (ergonomic `Entity`/`Key`/`Value`, struct↔entity mapping, maybe a derive) something you'd want? If so I'd treat that as its own design discussion rather than folding it in here.
- Given how #5592 went, is this a reasonable one for an outside contributor to take, or would you rather own it? If it's open, I'm happy to do the generation PR and leave any veneer work for a separate issue.

Scope I have in mind: just the generated data-plane client plus the build/test/doc wiring. Not planning to touch the veneer, release the crate (it'd stay `skip_release` until the surface settles), or change anything admin-side.