agent_integration_with_safe_bash_blocks flaky on CI: fixed 1000ms wall-clock threshold

[bug-ops]

Description

Same defect class as #6679 (closed by PR #6685, which rewrote 3 zeph-core tests to use structural concurrency proofs instead of wall-clock thresholds): tests/performance_agent_integration.rs::agent_integration_with_safe_bash_blocks asserts elapsed.as_millis() < 1000 around a fully-mocked Agent::run() call (MockProvider, MockChannel, InstrumentedMockExecutor — no real I/O), and intermittently fails under CI load.

Not covered by #6679/PR #6685 — that fix only touched the 3 named zeph-core unit tests; this is a separate top-level integration test in a different crate/file.

Reproduction Steps

1. Open a PR (confirmed on PR fix(sanitizer): redact PEM key bodies and no-prefix AWS secrets #6678, commit 6dc6da1, run 30355505115).
2. Observe Test (shard 5/8) (shard placement is hash-based, may land elsewhere on other diffs).
3. agent_integration_with_safe_bash_blocks intermittently panics.

Observed on PR #6678: failed on 2 of 3 attempts (elapsed 1.247s and 1.610s against the 1000ms budget), passed once.

Expected Behavior

The test should reliably verify the native tool_use path dispatches at least one tool call and completes without hanging, without depending on a fixed low-CPU-load wall-clock budget.

Actual Behavior

thread 'agent_integration_with_safe_bash_blocks' panicked at tests/performance_agent_integration.rs:231:5:
Agent run should complete: 1.609813557s

Environment

• Version: reproduced on PR fix(sanitizer): redact PEM key bodies and no-prefix AWS secrets #6678 (fix/6592-pem-secret-scrubber), commit 6dc6da1, rebased onto origin/main@c9ccb3919 (which already includes the 3 wall-clock timing tests are flaky on CI, blocking the required CI Status check #6679/PR fix: remove wall-clock-timing races from 3 flaky zeph-core tests #6685 fix for the other 3 tests)

Suggested fix direction

Same approach as PR #6685: either drop the timing assertion entirely (the test's real assertion of value is executor.get_call_count() >= 1, i.e. the native tool_use path was taken — the timing check adds no coverage beyond "didn't hang", which a bounded top-level test timeout already covers), or replace it with a much wider, CI-load-tolerant bound if a hang-detection budget is still wanted (e.g. several seconds, matching the sibling test's already-existing 2000ms comment: "2 s accounts for slow CI runners while still catching genuine regressions" — note the failing test's own bound of 1000ms is tighter than its sibling's 2000ms for what should be an equally cheap mocked call).