ci: fix production deploy skipping when invoked via workflow_call

[jirhiker]

Problem

Merging #711 created release v1.1.0 but never deployed it. In run 27302759728 the deploy-production / production-deploy job was skipped.

Cause

A reusable workflow inherits the caller's event context — github.event_name is never workflow_call. So in CD_production.yml:

if: ${{ startsWith((github.event_name == 'workflow_call' && inputs.tag_name) || github.event.release.tag_name, 'v') }}

github.event_name was push, the left side evaluated false, github.event.release.tag_name is empty on a push event, and startsWith('', 'v') → job skipped.

Fix

Drop the event-name check. inputs.tag_name is simply empty when the workflow is triggered by a release event, so || fallback behavior is preserved:

if: ${{ startsWith(inputs.tag_name || github.event.release.tag_name, 'v') }}

Same fix applied to the DEPLOY_TAG env expression.

Notes

• Must reach the production branch before the next release-please run picks it up (workflow_call resolves the called workflow at the pushed SHA).
• The release: published fallback path was never affected — re-publishing v1.1.0 from the UI will deploy it with the current code.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes a conditional in the production deployment GitHub Actions workflow so that production deploys no longer get skipped when the workflow is invoked as a reusable workflow via workflow_call (where the called workflow inherits the caller’s event context).

Changes:

• Simplifies the if: gate for production-deploy to select the deploy tag via inputs.tag_name || github.event.release.tag_name.
• Updates DEPLOY_TAG to use the same simplified fallback logic.
• Adds an inline note documenting the event-context behavior that caused the skip.