fix: coerce dry_run and boolean dispatch_inputs to real booleans in callback inputs

[joshua-temple]

Problem

A deploy reusable-workflow callback whose workflow_call.inputs.dry_run is declared type: boolean was receiving dry_run: ${{ github.event.inputs.dry_run }}. On push/schedule/workflow_run events that expression evaluates to an empty string. GitHub Actions requires a workflow_call boolean input to receive a real boolean and rejects the empty string, so the callback fails before any job materializes: the deploy shows result: failure with no visible job and Finalize aborts. PR #193 made the accessor null-safe but did not fix the empty-string-into-boolean coercion.

Fix

Emit dry_run: ${{ github.event.inputs.dry_run == 'true' }}, which is a real boolean valid on both push and dispatch: false on a push-triggered run and true only when an operator dispatches dry_run=true. Applied at all four sites that forward dry_run into a callback with: block (orchestrate plus the three promote deploy paths).

Audit of every value forwarded into a callback type: boolean input surfaced one sibling hazard: boolean dispatch_inputs forwarded as ${{ inputs.NAME }} share the same empty-string failure on non-dispatch events. Those are now coerced to ${{ inputs.NAME == 'true' }} when the dispatch_input is declared boolean; non-boolean inputs are forwarded verbatim. allow_breaking_changes, allow_downgrade, force, and the hotfix/rollback/release dry_run values are only consumed as env: strings or if: guards, never as callback boolean inputs, so they are unaffected.

Verification

• go build ./..., go test ./... (boolean-coercion cases green), and golangci-lint run ./... pass.
• New regression coverage for the orchestrate dry_run coercion and for boolean-vs-string dispatch_input forwarding; existing dry_run assertions updated to the coerced form.
• Dogfood regeneration produces no drift (the repo manifest declares no supports_dry_run or boolean dispatch_inputs).