Network modularity mismatch: strict gate uses lower value than persisted network_metrics

[RandomOscillations]

Summary

In extropy network, strict topology gating can fail on modularity while the persisted network_metrics.metrics_json.modularity for the same network id is above the configured minimum.

This creates contradictory outcomes:

• run is quarantined/rejected due to modularity fail,
• but saved metrics for that artifact show modularity in-range.

Repro

1. Run network with strict gate (default via balanced profile):
   • uv run extropy network -s <scenario> --validate --seed 42 --quality-profile balanced
2. Inspect latest network_runs.meta_json.quality.final_metrics.modularity and quality.bounds.modularity_min.
3. Inspect latest network_metrics.metrics_json.modularity for same network_id.

Observed (example)

• network_runs.meta_json.quality.final_metrics.modularity = 0.406678...
• network_runs.meta_json.quality.bounds.modularity_min = 0.45
• strict gate rejects (accepted=false)
• same artifact in network_metrics.metrics_json.modularity = 0.470425...

Expected

Modularity used for strict gate decision and persisted network metrics should match (or differences must be explicitly documented and both values persisted with labels indicating method/stage).

Why this matters

This makes network quality triage unreliable and repeatedly surfaces as an apparent modularity blocker even when reported metrics suggest pass.

Suspected area

extropy/population/network/generator.py gate path vs generate_network_with_metrics() + extropy/population/network/metrics.py modularity computation path/method consistency.