fix: make calculate() robust to omitted optional inputs

[dmchaledev]

Problem

The public calculate() API is documented to accept several optional fields — index.d.ts marks scan_window? and compliance_needs? as optional, and the README shows calculate({ /* inputs */ }). But the runtime didn't honor that contract:

calculate({ target_hosts: 1000, scan_intensity: 'medium', scan_frequency: 'weekly', scanning_tools: ['hailbytes_asm'] });
// ❌ TypeError: Cannot read properties of undefined (reading 'length')   ← compliance_needs

calculate({ target_hosts: 1000, scan_intensity: 'medium', scan_frequency: 'weekly', compliance_needs: [] });
// ❌ TypeError: Cannot read properties of undefined (reading 'includes') ← scanning_tools

calculate({ /* …no scan_window… */ });
// ⚠️ scan_window_utilization: NaN, efficiency_rating: 'poor'

So any consumer following the published types or the README quick-start hits a crash or gets NaN in the result. This is a contract mismatch between index.d.ts and the implementation, not just a theoretical edge case.

Fix

• Add a normalizeInputs() step at the entry of calculateResources() that fills safe defaults: empty arrays for scanning_tools/compliance_needs and a default 8-hour scan_window (matching the web component's own default). Empty arrays stay empty, so existing behavior (e.g. scanning_tools: [] → traditional path, $0 tool cost) is unchanged.
• index.d.ts: make scanning_tools optional to match runtime behavior, and drop the stale time_pressure field that was removed from the implementation in fix(test): use scan_window instead of non-existent time_pressure field #8.
• Add 4 regression tests covering each omitted-optional-field case.

Verification

npm test → 69 passing, 0 failing (4 new tests). No behavior change for fully-specified inputs.

🤖 Generated with Claude Code

---

Generated by Claude Code