Add contract tests, property-based tests, and architectural fitness tests

Problem

Our current test suite provides strong coverage for unit tests, integration tests, UAT, adversarial security testing, and CI-enforced code quality (linting, formatting, type checking). However, three testing gaps remain that leave us exposed to specific classes of defects:

1. No contract tests for cross-context interfaces

Our DDD architecture has 15 bounded contexts that communicate through repository interfaces, shared kernel types (events, errors), anti-corruption layers (ModelResolver), and Zod validation schemas. When one context's exposed interface changes — a schema validation rule is relaxed, an event shape drifts, or the ACL exposes different data — consuming contexts may break silently. We have no automated way to detect this beyond end-to-end integration tests, which test happy paths but don't systematically verify interface stability.

2. No property-based tests on aggregate invariants

Our aggregates enforce critical business rules: definition names reject path traversal, data always requires a type tag, workflow job names must be unique, data ownership is immutable. Currently these invariants are tested with hand-picked example inputs. Property-based testing would verify these invariants hold across a wide range of randomly generated inputs, catching edge cases that hand-written tests miss — particularly around unicode, empty strings, boundary values, and unexpected combinations.

3. No architectural fitness tests

Our DDD boundaries are enforced by convention and code review, not by automated tests. Nothing prevents a new import from creating a circular dependency between bounded contexts, a domain file from importing CLI code, or infrastructure leaking into the domain layer. These violations accumulate silently and erode the architecture over time. Automated boundary tests would catch violations immediately in CI.

What to add

• Contract tests for behavioral invariants at context boundaries — schema validation rules, event bus delivery semantics, ACL data exposure guarantees
• Property-based tests (using fast-check) for aggregate invariants — round-trip serialization, path traversal rejection, ownership semantics, normalization idempotency
• Architectural fitness tests — cycle detection in the BC dependency graph, layering rule enforcement (domain must not import CLI/presentation), domain-to-infrastructure violation ratchet

All tests should be standard Deno tests running in CI via deno task test, following existing project conventions.