[rustjava-tracing-attributes-pin-removal] fix: unfreeze tracing family by replacing the sole #[instrument] with a manual span

[Jun025]

What

java_runtime carried a direct tracing-attributes = "<0.1.29" pin to avoid the no_std compile error from #[tracing::instrument] (tokio-rs/tracing#3388). That pin froze the entire tracing family at 0.1.41 — tracing 0.1.44 requires tracing-attributes 0.1.31, so dependabot PRs (dlunch#149, dlunch#147) died as "no longer updatable". The only code forcing the pin was one #[tracing::instrument] in Thread's spawn callback.

Changes

• thread.rs: #[tracing::instrument(name = "java thread", fields(id = self.thread_id), skip_all)] → manual tracing::info_span!("java thread", id = self.thread_id) + .instrument(span) on the body. Same span name, field, level (INFO — instrument's default), and target; no attribute macro, so no_std-safe.
• java_runtime/Cargo.toml: direct tracing-attributes dependency + pin removed.
• workspace Cargo.toml: tracing's attributes feature dropped (no #[instrument] remains in the workspace).
• Cargo.lock (tracing family only, zero unrelated crates):
  • tracing 0.1.41 → 0.1.44 — the resolution that was previously impossible, proving the freeze is lifted
  • tracing-subscriber 0.3.20 → 0.3.23
  • tracing-attributes removed from the dependency graph entirely
• rust.yml: the wasm32 clippy step was missing workspace coverage (only the root package). Now --workspace --exclude test_utils. The exclusion is structural, not cosmetic: test_utils needs tokio rt-multi-thread, which hits tokio's compile_error! on wasm — a naive --all can never pass. Zero new warnings from the newly covered crates (classfile, java_runtime, jvm, jvm_rust, java_class_proto, java_constants) — no suppressions added, no follow-up split needed.

Evidence

• cargo test --all: 140 passed, 0 failed.
• cargo clippy --all -- -D warnings and cargo clippy --workspace --exclude test_utils --target wasm32-unknown-unknown -- -D warnings: clean. wasm32 is the no_std target the pin existed to protect — it builds clean without the pin.
• Span regression check: ran a Thread.start() demo binary with RUST_LOG=java_runtime=trace before and after; after stripping timestamps and the run-dependent thread id (a hashCode), the outputs are byte-identical:

  TRACE java thread{id=N}: java_runtime::classes::java::lang::thread: Thread start
  

Merge note

Same as #3: this PR also adds STATE.md/REPORT.md — later merges hit add/add conflicts; resolve by merging main into the remaining branch and taking the newest branch's superset versions.

Non-goals (per ticket)

• Pushing tracing to absolute latest is not the goal — unfreezing is; dependabot can take it from here.
• No upstream (dlunch/RustJava) contact.
• No observability redesign.

🤖 Generated with Claude Code