feat: add 'local' network + accept standalone aggregator status='ok'

[vrogojin]

Summary

Companion work for the sphere-sdk hermetic e2e stack (tests/e2e/local-infra/) which boots a local aggregator in BFT_ENABLED=false standalone mode. Stacked on top of #1 (which adds the critical-check verdict rule); merge order should be #1 then this.

Two changes:

1. `NETWORKS.local` in `src/networks.mjs` — endpoints for the docker-compose stack: aggregator `http://127.0.0.1:3001\`, nostr `ws://127.0.0.1:7777`, ipfs `http://127.0.0.1:8082\`. Fulcrum/Market intentionally non-local (no local counterpart yet). Faucet `null` — the local faucet is DM-driven, not HTTP, so the existing faucet probe doesn't apply.

2. Aggregator `/health` body parser accepts both shapes:

   • BFT mode (testnet/mainnet): `{"status":"healthy","database":"ok","aggregators":{...}}`
   • Standalone mode (the new local stack): `{"status":"ok","role":"standalone","details":{"database":"connected",...}}`

   Previously the standalone shape was reported as `degraded` even when the aggregator was fully functional. Now both are accepted; the verdict drops to `degraded` only on genuine unhealthy state.

Verified against the live local stack

Before:
```
⚠ aggregator http://127.0.0.1:3001 - DEGRADED
✗ health unhealthy: {"status":"ok","role":"standalone",...}
```

After:
```
✅ aggregator http://127.0.0.1:3001 - HEALTHY (4/4 checks passed)
✓ health 15ms ok role=standalone (db connected, 15ms)
✓ json-rpc 3ms OK — result={"blockNumber":"17"}
✓ submit_commitment 26ms accepted (status=SUCCESS, 26ms)
✓ get_inclusion_proof 2ms proof returned in 2ms
```

Tests

30/30 pass. Two new tests pin the new shape:

• `NETWORKS.local` has loopback endpoints + `faucet === null`
• `NETWORKS` keys updated to `['dev','local','mainnet','testnet']`

Test plan

• `npm test` — 30/30 pass
• Live probe against the local stack: `unicity-infra-probe --network local --only aggregator` → HEALTHY + exit 0
• Live probe against testnet still works (no regression to the BFT-mode parser path)

Bumps to 0.4.2.

[gemini-code-assist]

Code Review

This pull request introduces a local network configuration for docker-compose environments and updates the aggregator health probe to support both BFT and standalone response formats. The reviewer suggested refactoring the aggregator health check logic to explicitly distinguish between these two modes to prevent potential false positives and improve code clarity.

[gemini-code-assist]

The logic to determine if the aggregator is healthy is spread across several variables and has a fallback case that could lead to false positives. For instance, a minimal response like {"status":"ok"} would be incorrectly classified as healthy.

To improve clarity and correctness, I suggest refactoring this to explicitly check for the two distinct valid response shapes: one for BFT mode and one for standalone mode. This makes the code's intent clearer and avoids ambiguity. Using the role field, as described in the PR, would make the standalone check more specific.

    // Two health-body shapes are normal. We check for each shape explicitly.
    //   - BFT mode: { status: 'healthy', database: 'ok', aggregators: { … } }
    //   - Standalone mode: { status: 'ok', role: 'standalone', details: { database: 'connected' } }
    const isBftHealthy =
      body?.status === 'healthy' &&
      body?.database === 'ok' &&
      (body?.aggregators ? Object.values(body.aggregators).every((v) => v === 'ok') : true);

    const isStandaloneHealthy =
      body?.status === 'ok' &&
      body?.role === 'standalone' &&
      // `database` can be 'connected' or absent for some older standalone builds.
      (body?.details?.database === 'connected' || body?.details?.database === undefined);

    const happy = isBftHealthy || isStandaloneHealthy;