fix: Use KST (Asia/Seoul) instead of UTC for release date component

User caught this directly: it's already 2026-07-12 in Korea, but
Run #2008's release was tagged quant_20260711.3.7150737 -- the wrong
date.

Confirmed: UTC was still 2026-07-11 16:2x when KST was already
2026-07-12 01:2x (9-hour offset). prepare-release.yml computed
TODAY via `TZ=UTC date +%Y%m%d`, which is only "correct" if the team
operates on UTC -- but this project's production server logs,
deployment cadence, and team are all Korea Standard Time. Any release
cut between midnight and 9am KST would silently tag itself with
yesterday's date.

Fixed by using `TZ=Asia/Seoul date +%Y%m%d` instead.

.gitea/workflows/prepare-release.yml

@@ -39,7 +39,13 @@ jobs:
 
           # Auto-generate version if not provided
           if [ -z "$VERSION_INPUT" ]; then
-            TODAY=$(TZ=UTC date +%Y%m%d)
+            # This project operates on Korea Standard Time (production
+            # server logs, ops schedule, and the team are all KST) --
+            # using UTC here silently rolled the date back by up to 9
+            # hours (e.g. 2026-07-12 01:xx KST is still 2026-07-11 16:xx
+            # UTC), so a release cut right after midnight KST would tag
+            # itself with yesterday's date.
+            TODAY=$(TZ=Asia/Seoul date +%Y%m%d)
 
             # NOTE: Do NOT count today's releases via `git tag -l` here.
             # actions/checkout@v4 defaults to a shallow, single-branch