batch: POST entries keep a client-supplied id, unlike transaction and POST /[type] (#647)

[aacruzgon]

Summary

A POST entry in a batch bundle keeps a client-supplied resource.id, while the same entry in a transaction and the same body on POST /[type] get a server-assigned id. #647 decided that POST ignores the supplied id per http.html#create; the batch arm is the one path that missed it.

Reproduction (batch_conformance harness, in-memory SQLite)

{"request": {"method": "POST", "url": "Patient"}, "resource": {"resourceType": "Patient", "id": "client-chosen"}}

path	status	stored id
batch bundle	201	client-chosen
transaction bundle	201	server UUIDv7
POST /Patient	201	server UUIDv7

Cause

parse_bundle_entry (crates/rest/src/handlers/batch.rs:~2085) strips id on POST for the transaction path, and create_handler does the same (create.rs:102-107). process_batch_entry's POST arm passes the resource to storage().create untouched, so the backend honours the id, and a second batch with the same id answers 409, the #647 symptom.

Proposed fix

Strip id in the batch POST arm through the same helper the other two paths use, and add a batch_conformance case asserting the three paths agree.

Found while validating #511 (see PR #860).