feat(tracing): propagate log topic across spawns and label components

[varex83agent]

Summary

MetricsLayer labels app_log_warn_total / app_log_error_total with a topic taken from the nearest enclosing span, falling back to "". Because tracing span context does not cross tokio::spawn, and pluto set the topic field in only two places (health, stacksnipe), effectively every other warn/error landed under topic="".

This PR restores charon-like topic attribution:

1. Span-propagating spawn helper — pluto_tracing::spawn(fut) wraps the future with fut.instrument(Span::current()), so a subtask inherits the topic of the code that spawned it. Use it in place of tokio::spawn inside long-running components. Two unit tests assert the helper propagates the topic while a bare tokio::spawn does not.

2. Root topic span per long-running component — each component's entry point now carries a &'static str topic (keeping the label bounded), reusing charon's names.

Topics / components covered

topic	pluto site
sched	core/scheduler.rs actor run
tracker	core/tracker/mod.rs actor run
sigagg	core/sigagg.rs aggregate
bcast	core/bcast/mod.rs broadcast, core/bcast/recast.rs slot_ticked
parsigex	parsigex/behaviour.rs enqueue + notify_subscribers spawn
vapi	core/validatorapi/router.rs per-request middleware
qbft	consensus/qbft/runner.rs propose/participate/run_instance, component.rs cleanup spawn
p2p	p2p/p2p.rs handle_event
relay	cli/commands/relay.rs run, p2p/bootnode.rs relay-resolver spawn, relay-server/web.rs resolver spawn
peerinfo	peerinfo/protocol.rs send_peer_info / recv_peer_info
dkg	dkg/dkg.rs run (+ network-driver spawn via helper)
vmock	testutil/validatormock/component.rs slot_ticked / run_scheduler
app-start	app/node/mod.rs run (catch-all, mirrors charon's app.Run)

Pre-existing health and stacksnipe topics are unchanged.

Notes / deferred

• The DB actors (dutydb / parsigdb / aggsigdb) and the fetcher have no distinct charon topic; they fall under app-start, matching charon.
• The scheduler's subscribe_slot/subscribe_duty supervision loops run user callbacks belonging to other components, so they are intentionally left unlabelled at the loop level to avoid mislabelling callback errors under sched (the callbacks carry their own component topics).
• infosync has no charon topic mapping and was left as-is.

Quality gates

• cargo +nightly fmt --all — clean
• cargo clippy --workspace --all-targets --all-features -- -D warnings — clean
• cargo test --workspace --all-features — pass (incl. the two new spawn-propagation tests)

Closes #588

🤖 Generated with Claude Code