fix: name the child repository PR after the tag being released

[mjun0812]

Overview and Background

Every pull request this workflow has opened in a child repository was titled Update template to version latest, on a branch named after the run number, with an empty release notes line. The v2.0.2 run produced Update template to version latest (resolve conflicts) on template-update-9, so nothing recorded which template version was actually applied.

The workflow reads github.event.release.tag_name and falls back to latest. That fallback was meant for manual runs, but it is what always happens: the Release workflow creates the GitHub release with GITHUB_TOKEN, and GitHub does not raise workflow events for actions taken with that token, so the release trigger never fires from this repository's own automation. Only the push trigger does, and a tag push carries no release context. The run history confirms it, every run from v1.1.0 through v2.0.2 has event=push.

Related Issues

None. Third and last defect found in this workflow, after #40 and #41.

Implementation Approach

• A new Resolve template version step decides the version once: the release tag when a release event actually fires (a human publishing a release still works), otherwise the tag name from github.ref_name when the ref is a tag, otherwise latest.
• It emits three outputs: value for display, slug for the branch name, and release_url. The branch keeps using the run number when there is no version, so manual runs cannot collide on a template-update-latest branch.
• The release notes link is built from the tag instead of the release payload, which makes the line useful rather than always empty. The release exists by the time anyone opens the pull request, since the Release workflow runs on the same tag push.
• Context values reach the script through env: rather than direct interpolation, so no expression is expanded into the shell.
• The release trigger is kept. It is dead for this repository's automation but still correct if a release is published by hand.

Changes

• .github/workflows/trigger-template-update.yml: new version resolution step; title, body, commit message and branch use its outputs.

Impact

• The next release opens a pull request titled Update template to version v2.0.3 on branch template-update-v2.0.3, with a working link to the release notes.
• Manual runs are unchanged in naming: latest and a run-number branch.
• No change to the template, the generated project, or the Release workflow. Already open pull requests keep their current names.

Validation Results

Extracted the step's script with a YAML parser and ran it for each trigger path:

tag push (the real path)     -> value=v2.0.3 slug=v2.0.3 release_url=.../releases/tag/v2.0.3
release published by hand    -> value=v2.0.3 slug=v2.0.3 release_url=.../releases/tag/v2.0.3
workflow_dispatch            -> value=latest slug=11

Workflow security lint reports the same findings before and after this change, so nothing new was introduced:

uvx zizmor .github/workflows/trigger-template-update.yml
# 3 error[unpinned-uses], 1 warning[excessive-permissions]   (identical on main)

Those two pre-existing findings are untouched here: this workflow's actions are not SHA-pinned and it runs with default permissions, unlike the workflows hardened in #30.