Add tag‑based weekly scheduled incremental CI builds

[Arlodotexe]

What was changed

1. Scheduled Release Workflow (scheduled-releases.yml)

   • Renamed the old merge-weekly job to tag-weekly-release.
   • Added outputs for commit_range_start and commit_range_end.
   • Replaced the branch merge logic with a tag‑creation step that:
     • Creates a tag of the form release/weekly/<YYMMDD>.
     • Pushes the tag to the repo.
   • Added a commit‑range calculation step that:
     • Finds the previous release/weekly/* tag (or falls back to main).
     • Determines the SHA for the start and end commits.
   • Triggers the reusable build.yml job with those commit range values.

2. Build Workflow (build.yml)

   • Introduced inputs: commit_range_start and commit_range_end (both optional, defaulting to github.event.before/after).
   • Updated all checkout steps to use inputs.commit_range_end (or github.sha if missing) and enable fetch-tags.
   • Updated the Get-Changed-Components.ps1 invocation to use the new inputs, falling back to the default event values.

3. Miscellaneous

   • Minor cosmetic updates to job names and variable handling to match the new logic.

Why these changes

• Tag‑based incremental builds: The previous approach relied on merging main into the rel/weekly branch, but cron‑triggered workflows lose the github.event.before and github.event.after values. By creating a dedicated tag for each weekly release, we can reliably compute the commit range between releases.
• Reusable workflow inputs: Adding commit_range_start/commit_range_end as inputs keeps the build.yml reusable and makes the commit range explicit.
• Checkout consistency: All checkout steps now fetch the correct commit based on the new tag, ensuring the build runs on the intended code state.

Next steps (planned, optional)

1. Trigger the release workflow on tag pushes – update the scheduled-releases.yml workflow to support on: push: tags: 'release/weekly/*', so releases can be made by pushing a (protected) tag on a specific commit.
2. Automate GitHub Release creation – add a job/step in scheduled-releases.yml to create a GitHub Release from the newly created tag.

These items can be addressed in a subsequent PR once the tag‑based incremental build flow is fully validated.

[michael-hawker]

If the default when unspecified is included in the definition at the top, do we need the OR here still within the calls to GetChangedComponents here and below?

[Arlodotexe]

The default declared at the top only applies to reusable workflow triggers. We can probably remove them, since those variables are never provided by GitHub under that scenario.