Cosmos FFI Follow-Up: Docs, samples refresh, cleanup & soundness

## Part 1:

### Summary

Bring every doc and sample in line with the post-redesign ABI: add a Java <22 binding path, fix the submit-function name inconsistency, expand Go samples, and run a staleness pass over the README and `NATIVE_WRAPPER_SPEC.md`.

### Motivation

- @FabianMeiswinkel: (PR #4515 review) *"Java samples should be reworked — we have to support Java < 22."*
- @simorenoh: *"nit: this function was renamed to `cosmos_submit_singleton_operation` I believe, even see it as such in the README"* + offer to expand Go samples.
- Internal: the README and spec still describe removed/renamed APIs.

### Current state (verified)

- README Java sample uses the Java 22+ Foreign Function & Memory API (`java.lang.foreign`) only.
- `ASYNC_INVOCATION_ARCHITECTURE.md` shows an older submit name; the README uses a different one.
- README C#/Go/Python samples still call `cosmos_partition_key_builder_*`, `cosmos_completion_take_response`, and omit `partition_key_components`.
- `../azure_data_cosmos_driver/docs/NATIVE_WRAPPER_SPEC.md` still documents `cosmos_bytes_view_t`, `cosmos_operation_with_body`, `cosmos_driver_submit`, the builder APIs, and the `5001` advisory.

### Scope

- **In:** README (all language samples), `ASYNC_INVOCATION_ARCHITECTURE.md`, `NATIVE_WRAPPER_SPEC.md`, `DATA_MOVEMENT_DIAGRAMS.md` if affected.
- **Out:** any code change (docs/samples only).

### Work breakdown

- [ ] Add a Java <22 binding path (JNA or JNI shim) to the samples.
- [ ] Unify the submit-function name across README + architecture doc.
- [ ] Expand Go samples (CRUD + query + error paths).
- [ ] README/spec staleness pass: remove `*_builder_*`, `take_response`, `cosmos_bytes_view_t`, `cosmos_operation_with_body`, `cosmos_driver_submit`, `5001`; add `partition_key_components` / `body`+`body_len`.

### Acceptance criteria

- Java sample works on an LTS Java < 22.
- All docs reference the same, current submit symbol.
- Go sample covers common operations end-to-end.
- No doc references removed/renamed symbols; samples compile against the current header.
- `cspell` clean.

### References

FFI-10, FFI-14, FFI-15, FFI-18 in `FFI_FOLLOWUPS.md`.

## Part 2:

### Summary

Small internal-hygiene items: finish the dead-code sweep, harden the raw-pointer→reference helpers against lifetime misuse, and promote the driver crate to a workspace dependency.

### Motivation

- @FabianMeiswinkel: *"re-evaluate dead code — either delete or keep only when there are immediate changes planned."*
- Copilot bot: `from_ptr<'a>` mints a caller-chosen lifetime from a raw pointer — a latent hazard.
- Internal PR note: the driver crate is a path dependency, not yet a workspace dependency.

### Current state (verified)

- Most dead code was removed across P1–P6; a few `#[allow(dead_code)]` remain (e.g. `OwnedResponseHeaders.values` in `src/response_header.rs` — legitimate storage-only backing, keep with its comment).
- Safe `from_ptr<'a>(p) -> Option<&'a T>` helpers and `op_request::try_cstr_to_str<'a>` let the caller pick the output lifetime from a raw pointer. All current call sites consume the borrow within the same FFI call, so no active bug — a latent hazard only.
- `Cargo.toml` uses a path dependency on `azure_data_cosmos_driver` with an inline TODO.

### Scope

- **In:** `#[allow(dead_code)]` audit; lifetime hardening of the pointer helpers; `Cargo.toml` dependency change.
- **Out:** any ABI or behavior change.

### Work breakdown

- [ ] Grep every `#[allow(dead_code)]`; delete or add a one-line rationale.
- [ ] Mark the `from_ptr` / `try_cstr_to_str` helpers `unsafe fn` and/or tie `'a` to a borrowed input so the compiler enforces don't-escape.
- [ ] Promote `azure_data_cosmos_driver` to a workspace dependency; drop the TODO.

### Acceptance criteria

- Each remaining `#[allow(dead_code)]` has a rationale; no unused public surface.
- Pointer-helper lifetimes are compiler-checked or the fns are `unsafe` with a documented contract.
- `Cargo.toml` uses the workspace dependency.
- Full validation sweep clean.

### References

FFI-11, FFI-16, FFI-17 in `FFI_FOLLOWUPS.md`.