breg: ingestion-run client and audit follow-ups from #1188 final review round

Start with the Rust client request builder and derived bindings for the ingestion count ceiling, then inspect create_ingestion_run for request/response binding. Trace execute_batch_guarded, finish_ingestion_submission, and the service-refusal audit, using service_level_chunk_refusals_are_audited to enumerate duplicate-audit paths. Check the attempt persistence path for chunkIndex and verify all four follow-ups preserve refusal auditing and response-safe values.

Follow-ups accepted from the final review round of #1188 (round 15, four P2s). All four were verified or mechanism-confirmed against the code; all are non-critical consistency and availability edges on authenticated, creator-scoped surfaces, so they are tracked here rather than fixed in the PR.

1. Reject run-request counts above the protocol ceiling at build time (review)
   The client builder encodes an announcement with itemCount/inputLength/chunkCount above 2^53 - 1 even though parse_create_run_body always refuses it. Apply MAXIMUM_INGESTION_COUNT in the Rust client's request builder (and the derived bindings) so the maintained SDK cannot construct announcements the runtime always rejects. Verified: the round-14 bound was added to the server parser and to client decode, not to the request builder.

2. Bind created runs to their announcement (review)
   create_ingestion_run accepts a structurally valid 201 body for a different announcement without comparing the returned run's profile, operation, package/schema binding, input digest, or counts against the request, so a substituted body can be persisted as the successful result and drive later chunks against the wrong checkpoint. Mirror the request/response binding the round-14 fix added to submit/read/cancel/receipt (the announcement members are all echoed and comparable). Verified: create was the one run-scoped method left unbound.

3. Avoid auditing coordinator refusals twice (review)
   When a valid next-chunk request is refused inside the batch coordinator (normalization, validation, or mutation), execute_batch_guarded has already written the batch refusal audit, and the ingestion error arm writes a second HTTP refusal audit for the same request; if only the redundant second write fails, the deterministic refusal is promoted to service.unavailable. Audit integrity is security-sensitive per AGENTS.md, so the follow-up should either invoke the service-level audit only for errors raised before the coordinator or carry an already-audited marker. Mechanism confirmed in outline (finish_ingestion_submission + the service-refusal audit pinned by service_level_chunk_refusals_are_audited); the exact set of double-audited paths needs enumeration before the fix.

4. Reject oversized chunk indexes before persisting attempts (review)
   chunkIndex parses as i64 and the mismatch path persists it into last_attempt_chunk_index (column check is only >= 0), so an absurd index makes every later run document carry a count above 2^53 - 1, which the round-14 client decode refuses: the creator's own run becomes uninspectable and unresumable by every maintained client. Enforce the response-safe ceiling (MAXIMUM_INGESTION_COUNT) on the attempted index before persisting. Verified: Option<i64> storage, >= 0 check only, value rendered into the run document.