test: cover computeSemanticRules and enforcementPlanner

[OthmaneZ05]

Summary of Changes

NetworkService.computeSemanticRules is the single source of truth for "can X reach Y": it expands the canvas security groups into pairwise semantic rules, and its output feeds both the real iptables enforcement (EnforcementPlanner → DockerNetworkProvider) and the learning validators edge_exists / port_denied. It had no dedicated test; neither did EnforcementPlanner.

This PR adds that safety net, with no behaviour change:

• networkService.test.ts (34 cases) — default security groups, normalization (protocol casing, missing port/action, ICMP forcing port ALL), the ICMP twin of ALL/ALL rules, the three source expansion branches (0.0.0.0/0, subnet-…, node id), nodes not placed in a subnet, ASG replicas (parent-group inheritance, short container ids, running-only expansion, scaled-to-zero fallback), and degenerate configs.
• Rule order is rule priority. Enforcement and both validators walk these rules first-match-wins, so the output order is the policy. Several cases pin it explicitly (a narrow DENY prepended by the UI must shadow a later broad ALLOW). Reversing the rule iteration in computeSemanticRules makes 15 tests fail.
• enforcementPlanner.test.ts (7 cases) — 1:1 intent mapping, fail-closed on anything that is not exactly ALLOW, field pass-through, order preserved, terminal zero-trust DENY_ALL always appended last.
• virtualNetworkMapper.test.ts (+3 cases) — empty project, already-safe id, and the documented sanitization collision.
• Fixtures are realistic, never hand-built rules. Every config puts each node in a subnet with the canvas default group (deny all inbound / allow all outbound) and prepends the learner's rules, like the UI does — self-confirming fixtures have hidden real false-pass bugs before. The existing fixtures (makeDefaultSgRules, makeNetworkConfig) moved from the learning validators' testSupport to a new modules/network/testSupport.ts, where the config shape belongs; the learning testSupport re-exports them, so no validator test changed.

Typing, along the way and without touching behaviour: new SecurityGroupRuleInput / NetworkConfigInput in models/networkPolicy.ts, applied to the three config: any of NetworkService; ValidatorNetworkConfig now extends NetworkConfigInput instead of duplicating it with unknown[]. dockerNetworkProvider.ts is deliberately left untyped — out of scope here.

Types of Changes

• New feature / node type addition
• Bug fix (non-breaking change resolving an issue)
• Refactoring / structural cleanup
• Documentation update

Verification & Testing

Automated Checks

• Run npm run lint successfully with no errors
• Run npm run build successfully with no compilation errors
• Run npm test successfully (all tests pass)

Manual Verification

• npm test (backend): 439 tests / 37 suites green, up from 395.
• Mutation check: reversing the inbound rule iteration in computeSemanticRules fails 15 of the new cases; reverted.
• Non-regression against real Docker (no behaviour change to the enforcement path):
  • npx jest --config jest.integration.config.js src/modules/network/interSubnet.itest.ts → 5/5 green
  • npx jest --config jest.integration.config.js src/modules/learning/engine/engine.itest.ts → 20/20 green

Checklist

• My code follows the repository's code style and lint standards
• I have updated the documentation or instructions if necessary
• All unit and integration tests are passing