Compute labor supply response revenue_change instead of preserving legacy zero

Start with calculate_labor_supply_response(...) and review PR #360 to understand the existing LaborSupplyResponse output and legacy budgetary_impact_lsr behavior. Define the meaning and sign convention for revenue_change, then identify the available simulation outputs needed to compute it. Done means active runs produce tested non-zero effects, inactive runs remain zero, and any legacy divergence is documented.

Context

PR #360 (Add labor supply response macro output) adds a 4.x-compatible LaborSupplyResponse output that preserves the legacy macro output shape.

As part of that parity work, revenue_change is intentionally set to 0.0 because the legacy API initialized budgetary_impact_lsr to zero and never populated it. That preserves existing public behavior, but it leaves a real fiscal-effect gap: callers may reasonably interpret labor_supply_response.revenue_change as the tax/revenue impact caused by labor-supply responses.

Current behavior

calculate_labor_supply_response(...) computes LSR behavioral quantities such as:

• income_lsr
• substitution_lsr
• total_change
• relative_lsr
• decile average/relative breakdowns
• hours effects where supported

But revenue_change remains hard-coded to 0.0 for both active and inactive LSR paths.

Desired behavior

Determine and implement the correct fiscal calculation for LaborSupplyResponse.revenue_change, rather than preserving the legacy zero.

Acceptance criteria

• Define the intended meaning and sign convention for revenue_change.
• Compute revenue_change for active LSR runs using available simulation outputs or clearly documented additional required outputs.
• Preserve zero behavior for inactive LSR runs.
• Add focused tests for non-zero revenue effects, zero/inactive behavior, and sign convention.
• Document any intentional divergence from legacy budgetary_impact_lsr behavior.

Related PR: #360