Feature/add task search

[YusufsDesigns]

🔍 Implement Real-time Task Search

Closes #19

---

Overview

This PR adds a fully functional search bar to the top of the task list. As the user types, tasks are filtered in real-time based on their input. The implementation is intentionally non-destructive — the tasks array is never mutated during filtering — so Issue #9 (persistence), #10 (task renderer), and #13 (filter controls) can all build against the same state without conflict.

---

Changes

style.css

• Added styles for #search-container, #search-input, and all child elements using existing CSS design tokens — no hardcoded values
• Focus ring on the input uses color-mix() to derive a tinted glow from --color-primary automatically in both light and dark mode
• .search-icon transitions from muted to primary color when the input is focused via :focus-within on the container
• #search-clear and #search-no-results are hidden by default and shown by toggling a .visible class via JS — no inline style manipulation

script.js

• renderSearchBar() — injects the search bar markup (input, SVG icon, clear button) and a no-results message into their respective placeholder elements. Follows the existing JS-injection pattern so index.html stays untouched
• bindSearchEvents() — attaches input and click listeners after the markup exists in the DOM
• filterTasks(query) — iterates over rendered <li data-task-id> elements, looks each one up in the tasks array by ID, and toggles li.hidden based on a case-insensitive includes() match. The tasks array is never modified
• updateNoResultsMessage(matchCount, query) — shows a contextual "No tasks match '…'" message when zero items pass the filter
• toggleClearButton(query) — shows/hides the ✕ button whenever the input has text
• renderTasks() now calls filterTasks(searchQuery) at the end so any active search is automatically re-applied after a task is added, deleted, or updated without extra wiring

---

Architecture Decisions

Why DOM-only filtering instead of mutating tasks?
Keeping the tasks array intact means other contributors working on persistence (#9), the full task renderer (#10), and filter controls (#13) all read the same clean source of truth. Filtering is purely a presentational concern and is handled entirely in the DOM layer.

Why data-task-id as the bridge?
Each <li> carries a data-task-id attribute so filterTasks can look up the corresponding task object by ID and read its text for matching. This contract will hold when Issue #10 replaces the temporary renderTasks() with its full implementation — it just needs to keep the attribute on each list item.

Why type="search" on the input?
It gives mobile users a search-action keyboard, offers a native browser clear affordance as a fallback, and semantically describes the input's purpose to assistive technologies.

---

How to Test

1. Open the app — the search bar should appear above the task list
2. Type any partial word (e.g. "read") — only matching tasks should appear instantly
3. Case sensitivity — "READ", "Read", and "read" should all return the same results
4. Clear the input using the ✕ button — all tasks should reappear and focus should return to the input
5. Type a query with no matches (e.g. "zzzz") — a "No tasks match…" message should appear with the query term highlighted
6. Dark mode — toggle the theme and confirm the search bar, icon, focus ring, and no-results message all render correctly
7. Keyboard only — Tab to the input, type a query, Tab to the ✕ button, press Enter to clear

---

Notes for Teammates

• Never hardcode colors in new search-related styles — use the token variables so dark mode continues to work for free

---

Related Issues

Closes #19 — Implement Real-time Task Search

[MustaphaBakoji]

`the code is okay and meet the requirement