fix(cron): honor schedule time zones

[Alix-007]

📝 Description

Honor schedule.tz when computing the next run time for cron expressions so scheduled jobs execute in the intended timezone instead of always following the process default timezone.

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 📖 Documentation update
• ⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

• 🤖 Fully AI-generated (100% AI, 0% Human)
• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)
• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Related Issue

Fixes #1044

📚 Technical Context (Skip for Docs)

• Reference URL: [BUG] Cron expressions ignore schedule.TZ field, always evaluate in UTC #1044
• Reasoning: computeNextRun() now loads schedule.TZ, evaluates the cron expression in that location, and keeps the existing baseline behavior when the timezone is empty or invalid.

🧪 Test Environment

• Hardware: PC
• OS: Windows 11
• Model/Provider: N/A
• Channels: N/A

📸 Evidence (Optional)

Click to view Logs/Screenshots

• go test ./pkg/cron -run 'Test(SaveStore_FilePermissions|ComputeNextRun_UsesScheduleTimeZone)' -count=1

☑️ Checklist

• My code/docs follow the style of this project.
• I have performed a self-review of my own changes.
• I have updated the documentation accordingly.

[Alix-007]

Closing this to reduce duplicate PRs in the queue.

After re-checking issue #1044 and the current open PRs, this branch overlaps with existing open timezone-fix lines, especially #1046 and #1092.

The change itself is reasonable, but keeping a third open PR on the same schedule.TZ bug does not add much review value. It is better to let the maintainers choose among the already-open lines instead of continuing to maintain another duplicate branch.

If the other timezone PRs stall out and maintainers want this exact patch instead, it can be reopened from here or recreated cleanly on top of current main.