fix(replication)!: tune audit timeout policies

[mickvandijke]

Summary

This PR adjusts replication audit timeout policy in two commits:

1. Raises the responsible chunk audit timeout floor from 2 seconds to 4 seconds.
2. Removes the prune-audit-specific static 10 second timeout and the public ReplicationConfig::prune_audit_response_timeout field. Prune audit requests now use the same dynamic audit_response_timeout(key_count) helper used by responsible chunk audits.

Details

Raise chunk audit timeout floor

The minimum audit response deadline was previously 2 seconds. This PR raises AUDIT_RESPONSE_FLOOR_SECS to 4 seconds and updates the dependent timeout math/test expectations:

• audit_response_timeout(1) becomes 4.4s.
• audit_response_timeout(10) becomes 8s.
• audit_response_timeout(100) becomes 44s.

This keeps the existing per-byte scaling behavior while giving the hashes-only audit envelope more baseline room for cross-continent RTT and scheduling jitter.

Dynamic prune audit timeouts

Prune audits previously had their own static PRUNE_AUDIT_RESPONSE_SECS = 10 constant and public ReplicationConfig::prune_audit_response_timeout field. This PR removes that separate timeout/config surface and derives the prune audit request deadline from the encoded challenge key count:

let timeout = config.audit_response_timeout(key_count);

Today prune audit challenges still encode one key, but the timeout now follows the same dynamic path as responsible chunk audits and will scale correctly if prune challenges become batched later.

Semver

Breaking. ReplicationConfig is publicly re-exported from src/lib.rs, and this PR removes the public prune_audit_response_timeout field. Downstream struct-literal users must remove that field and allow prune audits to use audit_response_timeout(key_count).

The wire format is unchanged.

Testing

Ran:

cargo fmt --all -- --check
cargo test audit_response_timeout --all-features
cargo test prune --all-features
cargo clippy --all-targets --all-features -- -D warnings

[Copilot]

Pull request overview

This PR tunes replication audit timeout policy by increasing the minimum audit-response deadline and by aligning prune-audit request timeouts with the existing dynamic audit_response_timeout(key_count) sizing logic used for audit challenges.

Changes:

• Increased the audit response timeout floor from 2s to 4s and updated timeout-scaling tests accordingly.
• Removed the dedicated prune-audit timeout path and sized prune-audit request deadlines via audit_response_timeout(key_count).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/replication/pruning.rs	Computes prune challenge key_count and uses config.audit_response_timeout(key_count) when sending prune audit requests.
src/replication/config.rs	Raises AUDIT_RESPONSE_FLOOR_SECS to 4s, removes prune-audit-specific timeout constant/field, and updates timeout math/test expectations.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dirvine]

I can't approve this as a patch as-is.

The timeout behaviour itself looks sound: audit_response_timeout now gives 4.4s / 8s / 44s for 1 / 10 / 100 keys, and prune audits now derive their request timeout from the encoded challenge key count. Local checks passed:

• cargo fmt --all -- --check
• cargo test audit_response_timeout --all-features — 5 passed
• cargo test prune --all-features — 22 passed including the prune e2e filters

Blocker: ReplicationConfig is publicly re-exported from src/lib.rs, so removing the public prune_audit_response_timeout field breaks downstream struct-literal users while the PR says this is patch/no public API change. Either keep the field for compatibility (deprecated/ignored if necessary, still initialised in Default) or update the semver/release framing to acknowledge the breaking API change.

CI note: current head is dec0625bf4b6a13d2e3972cbba4d28d422d8d7ad; build/clippy/fmt/docs/security/no-logging test are green, but the OS test matrix was still pending when I checked.

[dirvine]

Re-reviewed current head a35f8eb977524b9d3a88a3b4ddb9063b5b80eaab after the API/semver note was updated.

The prior blocker is addressed: the public ReplicationConfig::prune_audit_response_timeout field removal is now explicitly marked as breaking in the title/body/semver notes.

Verified locally:

• git diff --check origin/main...HEAD — clean
• cargo test audit_response_timeout --all-features — 5 passed
• cargo test prune --all-features — 18 unit + 4 e2e prune tests passed

Code path checked: prune challenges still encode one key today, pass the derived key count through to send_prune_audit_challenge, and use config.audit_response_timeout(key_count); no protocol/runtime blocker found.

CI note: build/clippy/fmt/docs/security/no-logging checks were green when reviewed; OS test matrix was still pending, so merge should still wait for required checks.