scrape: apply_ipi_filter tracing span entered after async await — covers no work

[bug-ops]

Description

In crates/zeph-tools/src/scrape.rs, apply_ipi_filter creates a tracing span on line 1011, then calls filter_async().await (the actual blocking work), and only enters the span on line 1017 after the await completes. The span covers only the result-checking code — the IPI filtering itself is invisible in traces.

Reproduction Steps

1. Enable local tracing (telemetry.backend = "local")
2. Trigger a web scrape/fetch call
3. Open the trace JSON; look for tools.scrape.apply_ipi_filter span
4. Observe: span duration near zero, does not cover the filter_async work

Expected Behavior

Span duration includes filter_async execution time.

Actual Behavior

Span is entered after await, so it covers only a few microseconds of synchronous code.

Fix

Replace manual span enter/exit with #[tracing::instrument] on the function, or move _enter before the .await call. Since filter_async is async, #[tracing::instrument] is the correct approach.

// scrape.rs:1010-1017
async fn apply_ipi_filter(&self, body: &str, url: &str) -> Result<String, ToolError> {
    let span = tracing::info_span!("tools.scrape.apply_ipi_filter", url, body_len = body.len());
    let verdict = self
        .ipi_filter
        .filter_async(body.to_owned())
        .await   // <-- span not entered yet, miss the work
        ...;
    let _enter = span.enter();  // <-- entered here, too late

Environment

• HEAD: 07f96ae
• File: crates/zeph-tools/src/scrape.rs:1010