fix(api): keep re-entry attempts bounded and idempotent

[albertovincenzi]

Problem

The re-entry endpoint accepted an explicit attempt that was equal to or lower than the attempt already stamped on the item. A client could therefore reset the counter and keep an item cycling beyond maxAttempts. An untrusted JSON attempt was also cast from u64 to u32 and then incremented, allowing truncation or overflow. Finally, an empty txn made unrelated reports derive the same broker transaction ID and deduplicate each other.

Fix

• require a non-empty parent transaction ID
• parse the stamped attempt without lossy casts
• reject malformed, out-of-range, or non-incrementable stamped attempts
• require an explicit attempt to move strictly forward
• preserve the existing maxAttempts check for the resulting attempt
• add unit coverage for reset-to-zero, same-attempt replay, truncation, overflow, malformed stamps, and empty transaction IDs

Dependency

This PR is intentionally based on #8 so re-entry first receives the shared object-payload validation from that PR. The diff for this review is the single follow-up commit.

Review notes for Alice

Skipping forward remains legal: callers may choose a later attempt, but never the current or an earlier one. That keeps the endpoint bounded without forcing the caller to reproduce the exact next value. Duplicate reports of the same item and attempt still derive the same ID and remain idempotent.

Verification

• cargo test -p gate-server api::reenter::tests
• cargo clippy -p gate-server --all-targets -- -D warnings
• cargo fmt --all -- --check
• git diff --check

[alice-viola]

Landed on master via #67 (merge commit 944ee9b) as part of the 62-PR integration — this PR's head commit 49a1412 is an ancestor of master. GitHub could not mark it merged automatically because its base is fix/reject-non-object-payloads, not master. Closing as landed.