[Code Health] Warn when task fanin/fanout exceeds 16 during dependency construction

[yanghaoran29]

Summary

Closes hw-native-sys#1261. Very large fanin/fanout is a code-health smell (cf. hw-native-sys#959) — it makes the dependency graph hard to reason about and can hide an unexpectedly dense wiring shape. Nothing flagged it before.

This adds a two-part, bounded diagnostic, split by the phase where each degree is naturally constructed:

1. Immediate WARN during execution (high-water gated)

Per codestyle rule 7 (never flood the AICPU device log on the hot path), each metric warns only on a new high-water max above the threshold:

• Fanout — pto_orchestrator.cpp::append_fanin_or_fail, where the orchestrator increments each producer's fanout_count per claimed consumer. The value is captured under fanout_lock and logged after unlock (no logging in the critical section).
• Fanin — pto_scheduler.h::wire_task, where scheduler thread 0 wires a task's fanin edges (wfanin), gated on a per-ring high-water.

2. End-of-run summary

Every task/producer over the threshold is counted silently during the run, then one line per metric is emitted at teardown:

• === [Orchestrator] tasks with fanout>16: N === in mark_done()
• === [Scheduler] tasks with fanin>16: N === in SchedulerContext::shutdown() (thread 0)

Counters reset per run. Threshold PTO2_DEP_DEGREE_WARN_THRESHOLD = 16. Purely diagnostic — no behavior change, no new env/macro gate. Mirrored to a2a3 and a5.

Test

Adds a dummy_task st case (DenseFanoutFanin, case=4): one producer fanned out to 18 dummy barriers, then one consumer depending on all 18, so both degrees exceed the threshold.

Verified on a2a3sim + a5sim (both pass):

[WARN] append_fanin_or_fail: dense dependency: task ring=0 id=0 fanout=17 (>16) [orch submit]
[WARN] append_fanin_or_fail: dense dependency: task ring=0 id=0 fanout=18 (>16) [orch submit]
[WARN] append_fanin_or_fail: dense dependency: task ring=0 id=0 fanout=19 (>16) [orch submit]
[INFO_V0] mark_done: === [Orchestrator] tasks with fanout>16: 1 ===
[WARN] wire_task: dense dependency: task ring=0 id=19 fanin=19 (>16) [scheduler wiring]
[INFO_V0] shutdown: === [Scheduler] tasks with fanin>16: 1 ===

18 consumers → only 3 WARN lines (one per new max) confirms the flood guard. Summaries need --log-level v0; the WARNs show at the default level.

Notes

• Fires at 17/18/19 (not 16) because "greater than 16" is strict and the case-4 consumer also reads X, making the producer's true fanout 19. PTO2_FANIN_INLINE_CAP is 64, so 16 is an advisory policy threshold, not a structural boundary.
• Onboard hardware verification wasn't possible in this environment (NPU dcmi init fails, arch precheck refuses); the sim runs exercise the identical orchestrator/scheduler code paths.

🤖 Generated with Claude Code