batch/transaction: dispatch $operation entry URLs instead of refusing them as an unknown resource type

[aacruzgon]

Summary

Bundle entries whose URL names an operation (POST ValueSet/$lookup, POST Patient/123/$everything) are refused rather than dispatched, and the refusal calls the operation a resource type. The spec's own transaction example, vendored at crates/fhir/tests/data/json/R4/bundle-transaction.json (entry 7), uses POST ValueSet/$lookup with a Parameters body.

Current behavior (reproduced on the batch_conformance harness)

• batch: entry answers 400 Bad Request with Resource type '$lookup' is not supported for FHIR R4; nothing is created.
• transaction: whole bundle answers 400 with the same text.

So no bogus resource is written (an earlier reading of the code suggested one would be); the gap is purely that operations are not dispatched from bundle entries at all.

Proposed shape

1. Parse [type]/$op, [type]/[id]/$op and $op entry URLs before the resource-type check, and refuse them with a message that says operations are not supported in bundle entries.
2. Dispatch the operations HFS already implements at the REST layer ($validate, $everything, $export kick-off is out, terminology operations via the configured HTS proxy) through the same handlers, with per-entry results in batch and whole-bundle failure in transaction.
3. Add the spec fixture as a conformance test once it can run end to end (its conditional entries are covered by batch/transaction: conditional interactions are refused rather than resolved — wire bundle entries to ConditionalStorage #511/transaction: resolve URL-borne conditional criteria (PUT/DELETE [type]?[criteria]) inside the atomic scope #859).

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