fix(kerykeion): drop the redundant Instrument import from collector_tests

[forkwright]

Finding

gate / full-gate-build fails on main, which blocks release PR #465 (chore(main): release 0.6.2, open 8 days). gate / gate reports failure too, but it is a downstream reporter of the
same result — one cause, not two.

Evidence

gate / full-gate-build step check, verbatim:

error: unused import: `tracing::Instrument`
--> crates/kerykeion/src/collector_tests.rs:4:5
|
4 | use tracing::Instrument as _;
| ^^^^^^^^^^^^^^^^^^^
= note: `-D unused-imports` implied by `-D warnings`
error: could not compile `kerykeion` (lib test) due to 1 previous error

gate / gate (job 98205969995) then reports:

BUILD_RESULT: failure
ERROR: no Gate-Passed trailer, not a docs-only changeset, and full-gate-build did not succeed

This is not the release commit's doing.gh pr diff 465 touches only
.release-please-manifest.json, CHANGELOG.md, Cargo.lock, Cargo.toml.
crates/kerykeion/src/collector_tests.rs is byte-identical between origin/main and the release
head, so the fix belongs here on main.

Why this matters

collector.rs:688-690 declares the test file as a child module:

#[cfg(test)]#[path = "collector_tests.rs"]mod tests;

collector.rs:15 already carries use tracing::{Instrument as _, instrument};, and
collector_tests.rs:6 opens with use super::*;. A non-pub item is visible to its defining
module and its descendants, so that glob already brings Instrument into scope — the file's own
line 4 binds a name it would have either way.

Desired correction

Delete line 4 and its trailing blank. The two .instrument() call sites (lines 258, 332) keep
resolving through use super::*;, and collector.rs keeps its own import — it uses both the trait
and the #[instrument(...)] attribute macro directly.

Done when:full-gate-build passes on main and #465's gate / gate goes green.

WARNING — the detection is non-deterministic, the defect is not

The same check command over these byte-identical files passed on a main-push run 15 hours
earlier (run 32907547269, job 97994832002, same pinned toolchain 1.97.1) and failed here.
Swatinem/rust-cache shares one key (gate-attestation) across the push and pull_request
triggers, so an incremental cache hit can let rustc skip re-linting this compilation unit.

The import is unconditionally redundant and removing it is correct regardless of cache state — but
treat a green run on this workspace as not evidence that a -D warnings lint is absent. That
shared cache key is worth a separate look.