fix(freehire-search): emit the contract's YYYY-MM-DD date instead of the API's ISO timestamp (#621)

toResult passed posted_at through verbatim, so search and detail JSON
carried "date": "2026-07-06T00:00:00Z" while every other portal CLI
emits the date part only and /scrape stores it as
posted_date: "YYYY-MM-DD". The table and plain renderers already cut the
value to ten characters, so only JSON consumers - the /scrape path - saw
the raw timestamp.

Add contractDate(): the timestamp's date part, null for an absent or
non-date value. The two tests that pinned the raw timestamp now expect
the date and fail on master, plus three cases on the helper. SKILL.md
documents the shape.

.agents/skills/freehire-search/SKILL.md

@@ -191,7 +191,7 @@ dictionaries never guess). So:
   tracking (apply/save) needs a key, and this skill deliberately does not touch it:
   it is **search + detail only**.
 - `id` in search results is the freehire `public_slug` — pass it as-is to `detail`.
-- `date` is the posting date (`posted_at`); it may be `null` for undated postings.
+- `date` is the posting date as `YYYY-MM-DD` (the date part of the API's `posted_at` timestamp, the shape every portal CLI emits); it may be `null` for undated postings.
 - Facet values are controlled vocabularies. Use `/api/v1/jobs/facets` to see the
   live values (with counts) for a query before filtering.
 - The API retries 429/5xx with exponential backoff; an unreachable API exits