feat(governance): make analysis deterministic with ChangeContext (#79)

[ElliotSun]

Summary

Implements #79 by making governance-relevant date context explicit, reproducible, and owned at the application-service boundary.

Changes

• adds a minimal immutable ChangeContext containing only required effective_date
• adds UI-independent semapact.services.GovernanceService as the application boundary that constructs ChangeContext
• keeps CLI/UI/API concerns limited to supplying request values; interfaces do not construct domain context
• includes context in serialized GovernanceDecision
• threads the same resolved context through merge and governance evaluation
• removes implicit wall-clock date resolution from lifecycle auto-deprecation
• uses effective_date for generated schema/property deprecationDate
• preserves an existing deprecationDate rather than overwriting it
• includes effective_date in deterministic decision identity
• persists the effective date in batch release tasks so later execution restores the same semantic date
• updates architecture/service-layer guidance and regression coverage

Context ownership

effective_date is the semantic date under which the contract change is evaluated. It is not an execution timestamp, PR timestamp, Git timestamp, or release timestamp.

CLI / UI / API request
    effective_date value
            ↓
GovernanceService
    constructs ChangeContext once
            ↓
merge → governance evaluation → release artifacts

Lower layers consume the supplied ChangeContext. They must not generate, default, overwrite, or re-resolve it from the wall clock.

Until a persistent Draft/ChangeSet workflow owns and stores the effective date, current CLI governance operations accept an explicit --effective-date YYYY-MM-DD. This is a request value, not CLI ownership of ChangeContext.

Architectural boundary

ChangeContext is SemaPact runtime governance input, not an ODCS extension. This issue intentionally does not add actor, Git revision, DAB metadata, policy version, or release/version-authority fields.

Release/version authority is tracked separately in #166.

Validation

• service-level tests verify context construction and reuse across merge/evaluation
• regression tests verify deterministic decisions and explicit auto-deprecation dates
• existing deprecation dates are preserved
• batch release manifests preserve the effective date
• full CI passes on Python 3.11, 3.12, 3.13, and 3.14

Closes #79