Fix: "Create your first routine" CTA opens Task form instead of starting routine flow

[sambhavi0]

📌 Description

On an empty Routine Builder page, clicking "+ Create your first routine" opened the Task creation modal (Title, Priority, Due Date, Repeat, etc.) instead of starting the actual routine-building flow, since the empty state's CTA was wired to the same handler used for adding tasks to the library. This PR fixes that by giving the routine empty-state CTA its own logic: if the user already has tasks to work with, it scrolls up and highlights the weekly grid to guide them toward drag-and-drop scheduling; only if their task library is empty does it fall back to opening the Task form, since a task is needed before anything can be scheduled.

🔗 Related Issue

Closes #1563

🛠 Changes Made

• RoutineBuilder.jsx: added handleStartRoutine, which branches on whether the task library has tasks pulses/highlights the grid if so, opens the Task modal if not
• RoutineBuilder.jsx: added highlightGrid state, passed to WeeklyGrid as a highlight prop
• RoutineBuilder.jsx: rewired the "Saved Routines" empty state onAction from handleOpenModal to handleStartRoutine
• WeeklyGrid.jsx: accepts new highlight prop shows a cyan ring/glow and a short inline hint ("Drag a task from your library onto the grid to start building a routine") when active
• No backend or schema changes; the existing Save Routine flow (Name + Description) was already correct

📸 Screenshots (if applicable)

✅ Checklist

• Code runs locally
• Followed project structure
• No console errors
• Properly tested changes
• Linked the issue

🚀 Notes for Reviewers

This issue originally described the routine creation form collecting task fields (Priority, Due Date, Repeat), but after digging in I found that form belongs to TaskFormModal (task creation) the actual routine save flow already only asks for Name + Description, which was correct. The real bug was narrower: the "Create your first routine" empty state button was wired to open that same Task form instead of guiding the user toward the drag and drop scheduling flow, so this PR fixes that specific wiring. I left a comment on the issue explaining the re scope before starting work, happy to adjust if you'd rather handle it differently. Verified with eslint and a production build (both clean), but wasn't able to do a full manual click-through locally due to local env setup issues, so flagging that in case you'd like to test the highlight/pulse behavior yourself before merging.

[sambhavi0]

Just opened a pr for issue #1563. Kindly lmk if any changes are required @aryandas2911