fix(network): make peer maintenance safe and enforce data capacity

[QuickMythril]

Summary

This combines the reviewed peer-maintenance, Previewnet lifetime, and
NetworkData capacity work into the exact integration that passed local
acceptance.

• use the controller's existing 120-second startup / 90-second recurring
  cadence as the single peer-maintenance clock
• rotate at most one eligible outbound chain peer per pass, preserving
  inbound, fixed, syncing, and low-peer-protected connections
• replace fixed-age data churn with meaningful-idle outbound rotation while
  protecting queued, in-flight, output, relay, and prefetch QDN work
• keep routine file-list gossip from indefinitely refreshing meaningful idle
• validate peer lifetime/idle settings and accept
  maxDataPeerConnectionTime as a one-release compatibility alias
• make maxDataPeers authoritative across TCP, I2P, ordinary outbound, and
  force-connect admissions, with one provisional admission reservation
• expose effective data capacity and pending admissions in peer diagnostics
• prefer non-cooled replacement endpoints after voluntary rotation while
  allowing the cooled endpoint when it is the only viable candidate
• set all tracked Previewnet profiles to randomized two-to-six-hour chain
  lifetimes instead of the inherited effectively disabled value
• make disconnect write-channel cleanup null-safe

The commits remain separated by policy, capacity, Preview configuration,
integration documentation, test-fixture cleanup, and defensive cleanup so the
three review lanes can be inspected independently.

Validation

• focused integrated set: 66 tests, 0 failures, 0 errors
• clean full suite: 2,815 tests, 0 failures, 0 errors, 64 skipped
• aggregate verification across 305 Surefire XML reports
• no Surefire dump/dumpstream files
• git diff --check main...HEAD

Controlled acceptance on a local Home-managed, I2P-only Previewnet
participant verified:

• first maintenance pass 120 seconds after startup and recurring passes at
  approximately 90 seconds
• exactly one outbound chain rotation per pass, with aged inbound
  reconnections preserved
• recent meaningful QDN request activity prevented data-idle rotation
• an idle outbound data peer rotated on the next eligible controller pass
• diagnostics reported the configured data capacity and no leaked pending
  admissions
• refill preferred alternate endpoints, then used the cooled endpoint as a
  fallback when those alternatives failed
• Core remained synced and minting-capable

The published local Core jar, settings, template snapshot, and logging
configuration were restored byte-for-byte after acceptance.

Rollout

No managed Previewnet seed has received these changes. After review and a
release build, roll out one seed at a time, verify sync/minting/peer recovery,
and observe at least 48 hours (two expected rotation windows) before widening
the rollout.