test(rest): pin the issue codes on #478's two search-entry failure paths

[aacruzgon]

Summary

#481 added search-entry dispatch to both bundle arms, and with it two new failure sites — one per
arm — with no coverage on either. All five of its tests assert 200 OK.

Both sites were written as:

Err(e) => {
    let (status, _, details) = e.client_response();
    create_error_result(status.as_u16(), &details)
}

That is the same code-discard #504 removed from every other call site in the file: client_response
computes the correct FHIR issue code, the _ throws it away, and the wrapper stamps processing over
the result. Left alone, a search entry would have been the one path in the handler still answering
processing after #504.

The rebase below this commit migrated both to entry_failure. This PR pins that, so they cannot
drift back.

Changes

Three tests in batch_entry_issue_codes.rs:

Test	Drives	Asserts
a_failed_search_entry_reports_its_issue_code	batch: Patient?_query=byName, Patient?code:not-in=…	400 invalid, 501 not-supported
a_failed_transaction_search_entry_reports_its_issue_code	transaction: Patient?_query=byName	400 invalid, per-entry, bundle still 200
a_failed_search_is_described_identically_by_both_surfaces	both surfaces, same bad search	severity, code and details.text all agree, plus a literal pin

The parity test's literal pin is load-bearing: processing == processing satisfies the three
equalities on its own, so without it a regression that flattened both surfaces would pass.

The transaction case corrects a claim #504 made

#504 stated that no per-entry outcome is reachable on the transaction arm — the backends discard an
entry result at their status >= 400 guard and return TransactionError::BundleError, which carries
neither a status nor a code. That was true of the tree #504 landed on. It is false here. #481's
search loop bypasses the backend executor entirely and surfaces a search failure as that entry's own
outcome, deliberately — a failed search cannot roll back writes that already committed.

So this is the first reachable per-entry outcome on the transaction arm, and the first place its issue
code is asserted. #504's PR body and README say otherwise; the README bullet is corrected below and
the claim is narrowed to the tree it was true of.

Documentation

Removes a Current Limitations bullet #504 added:

Bare type-level GET — GET Patient in a batch entry is read as an instance read with an empty
id and answers 404 not-found with the message Resource Patient/ not found. Executing it as a
search is #478.

That work is the commit directly below this one, so the bullet is now false. Removed rather than left
to mislead. The per-entry code table gains a row for search-entry failures, and the parity sentence
gains the search surface.

Testing

cargo test -p helios-rest   →  1117 passed, 0 failed
cargo fmt --all --check     →  clean

Verified non-vacuous. With both sites reverted to their original code-discard, all three fail:

left: String("processing")   right: "invalid"
left: String("processing")   right: String("invalid")
left: String("processing")   right: "invalid"

Clippy: CI's invocation (ci.yml:497, which carries -A collapsible_if and seven sibling allow-flags) passes clean — exit 0, zero errors. Worth correcting explicitly, because this PR previously repeated the parent PRs' claim that the gate "still exits 101 on pre-existing lints tracked in #513": that is true of the bare cargo clippy --all-targets --all-features -- -D warnings, but not of what CI runs. All 42 crates/rest warnings and all six files that fail the bare form sit inside the allowed lint families, so the Linting job was never going to fail. Separately measured: crates/rest lint set is 42 → 42, zero introduced, zero removed against the base with forced recompilation.

Notes

• Stacked on fix(rest): execute search-style GET bundle entries as searches #481, which was rebased from main onto fix(rest): render batch entry failures through the single-resource error mapping #516 to make this possible — the
  reconciliation needs entry_failure, which only exists after batch: every per-entry error carries OperationOutcome code processing — a 403, 404 and 405 are indistinguishable without parsing English #504. angela's original branch is
  preserved at backup/481-original-pre-restack; the rebase and its five-hunk resolution are
  described in a comment on #481.
• Why both failures are drivable: execute_search_bundle rejects _query as a known-but-
  unimplemented control parameter (InvalidParameter → 400 invalid) and :not-in as a modifier no
  backend implements (NotImplemented → 501 not-supported). Two different codes through one path,
  which is what makes the test meaningful rather than a single-value check.
• Not covered: a search entry failing inside a transaction after other entries have committed.
  The behaviour is deliberate and documented in the code, but asserting it needs a bundle whose write
  entries commit and whose search then fails, and the ordering that makes it deterministic is
  method_processing_order's, not something a test should depend on. Left as-is.

Refs #478, #504

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[aacruzgon]

Closing: this PR existed only because the search-entry failure sites lived on the #481 commit that #516 carried. #481 reached main through #635, and #516 has been rebased onto that. The three tests here still pin something real — that a failed search entry renders invalid / not-supported through entry_failure rather than processing — so the commit was cherry-picked onto #516 unchanged (36a614b18) instead of being dropped. Nothing is lost; there is just no separate PR for it any more.