Avoid macro cache initialization when reads are disabled

[MaxGhenis]

Summary

• Instantiate SimulationMacroCache only after check_macro_cache confirms a macro-cache read is available.
• Avoid repeated package metadata lookups for ordinary household simulations where macro-cache reads are disabled.
• Add a regression test that default calculations do not construct the macro cache.

Context

This surfaced while investigating elevated household API latency on requests that include Medicaid outputs. The broader Medicaid calculation graph comes from PolicyEngine/policyengine-us#8169, which fixed MAGI Medicaid household construction by moving from a tax-unit proxy to person-specific tax-filer and non-filer rules.

That policyengine-us change is valid model behavior, but it expands the number of variables calculated for Medicaid. In household simulations, macro-cache reads are normally unavailable, yet Simulation._calculate was still constructing SimulationMacroCache before checking availability. That constructor reads package metadata, so the expanded Medicaid graph turned a small per-variable overhead into a noticeable latency regression.

In a local reproduction using the current household API stack and a partner-style payload with Medicaid among requested outputs, warm /us/calculate endpoint timing was about 2.5s on current core and about 0.36-0.64s with this patch. The change preserves the existing macro-cache read path when a cache is actually available.

Testing

• uv run pytest tests/core/test_simulations.py::test_calculate_without_macro_cache_does_not_build_macro_cache tests/core/test_simulations.py::test_macro_cache -q
• uv run ruff check policyengine_core/simulations/simulation.py tests/core/test_simulations.py