feat(ffi): batched public upload (single payment) + result cost/chunk parity (V2-645, V2-646)

[Nic-dorman]

Two tickets from the 0.0.8 break-window bundle (milestone ②):

V2-645 — wallet-path public upload pays twice

file_upload_public / file_upload_public_with_progress previously did a private upload (payment 1) followed by a standalone paid data_map_store (payment 2). They now call ant-core's batched file_upload_public_with_mode / file_upload_public_with_progress, which store the serialized data map in the same payment batch as the file's chunks — one payment, and the quote/estimate lines up with what's actually charged (also resolves duplicate V2-610). The shareable address comes from FileUploadResult::data_map_address (always Some for public uploads; None is surfaced as an internal error).

V2-646 — wallet-path results drop cost/chunk fields

FilePutPublicResult and FilePutPrivateResult were bare (address / data_map only) while ExternalUploadResult exposes chunk and cost details. Both records now carry chunks_stored, storage_cost_atto, gas_cost_wei, payment_mode_used — matching ExternalUploadResult naming and the DataPut* results' payment_mode_used. Shape parity done now, before 0.0.8 freezes the record shapes.

Notes

• Bytes-path residual: data_put_public still stores the data map as a separate paid call — core has no batched bytes upload at the 0.3.1 pin. Noted on V2-645; would need an upstream API to fix.
• Record field additions + no signature changes: bindings regenerate in lockstep at the 0.0.8 release cut (V2-686), and ffi-ci validates the export surface at PR time.
• Gates: cargo fmt --check + clippy --all-targets --all-features -- -D warnings clean, 11/11 tests.

Holding merge pending review + Nic's go-ahead.

🤖 Generated with Claude Code

[dirvine]

Hermes review — ant-sdk PR #219

Head: f582c9434ff4 (1 commit on main, feat/ffi-batched-public-upload-0.0.8 → main).
Verdict: comment (advisory, no severe blockers). Looks ready to merge after the bundle lands — a few non-blocking caveats below.

What this PR does (verified against ant-core 0.3.1)

• file_upload_public / file_upload_public_with_progress now call ant-core's batched file_upload_public_with_mode / file_upload_public_with_progress (file.rs in ant-core 0.3.1 / tag ant-cli-v0.2.11). One payment covers the file chunks + the serialized data-map chunk; previously it paid twice (file chunks, then a standalone paid data_map_store).
• The wallet-path FilePutPublicResult / FilePutPrivateResult gain chunks_stored, storage_cost_atto, gas_cost_wei, payment_mode_used, parity with ExternalUploadResult and the DataPut* results. Additive #[uniffi::export(record)] — bindings regenerate cleanly at the 0.0.8 cut.
• data_map_address is Option<…> in core; the new to_file_put_public_result correctly maps None → ClientError::InternalError. Verified at client.rs:1217 in the PR head.
• Lockfile: no Cargo.lock change in this PR's diff (git diff --stat origin/main...HEAD -- '**/Cargo.lock' is empty). Security Audit fail, if any, is inherited from the base branch — not introduced. Not a blocker here.
• Local verification on detached worktree at /tmp/pr-219-wt.CFTqt3 (head f582c9434ff4):
  • cargo fmt --all -- --check — clean
  • cargo clippy --all-targets --all-features -- -D warnings — clean
  • cargo test --lib --no-fail-fast — 11/11 pass (matches the PR's claimed count)
• CI: Check (ant-ffi) + Security audit — both green on the PR head.

Non-blocking caveats

• Bytes-path residual: data_put_public still stores the data map as a separate paid call — the PR body explicitly notes this and points at "needs an upstream API to fix". Not a blocker for this PR; just tracking.
• From<ant_core::data::Error> arm list — unchanged here. Error::PartialUpload is still mapped to InternalError in the other => … fallthrough at lib.rs:333 on this PR head. The proper mapping is added by feat(ffi): PartialUpload error, private-download + estimate-progress variants, version accessor (V2-644, V2-611, V2-654, V2-658) #221 which adds ClientError::PartialUpload { … } and the matching arm. Since feat(ffi): batched public upload (single payment) + result cost/chunk parity (V2-645, V2-646) #219 is the first PR in the merge order, mobile apps on the 0.0.8 SDK that hit a partial upload between the feat(ffi): batched public upload (single payment) + result cost/chunk parity (V2-645, V2-646) #219 merge and the feat(ffi): PartialUpload error, private-download + estimate-progress variants, version accessor (V2-644, V2-611, V2-654, V2-658) #221 merge will see a generic InternalError rather than the structured PartialUpload. Suggest the merge order stay strict: feat(ffi): PartialUpload error, private-download + estimate-progress variants, version accessor (V2-644, V2-611, V2-654, V2-658) #221 must land before any mobile release that ships only feat(ffi): batched public upload (single payment) + result cost/chunk parity (V2-645, V2-646) #219. Cross-link this in the release checklist so the half-state doesn't ship to users.
• FilePutPrivateResult vs ExternalUploadResult shape parity — not yet unified. ExternalUploadResult (the external-signer path) has chunks_stored/storage_cost_atto/gas_cost_wei plus data_map: String. FilePutPrivateResult now has the same cost fields plus data_map. FilePutPublicResult has the same cost fields plus address: String. The three records are field-parallel except for the address vs data_map split — looks intentional and reasonable for the wallet path.

Recommendation

Approve once the maintainer confirms #221 will merge before any 0.0.8 release cut (so mobile never sees the half-state where PartialUpload is still generic). The diff itself is clean.

— Hermes Agent (panel review for #219 of the 0.0.8 break-window bundle)

[Nic-dorman]

Merge-order constraint confirmed and recorded on the release plan (V2-686): #221 lands before any 0.0.8 release cut, so mobile never ships the half-state where PartialUpload still surfaces as a generic InternalError. Planned order: #219 → #220 → #221 (+#222 together) → #223.