[Bug] /watch accepts an unreadable days: filter and silently drops it

[Berniebiloxi]

Environment

Not runtime-specific — found by reading src/filters.ts / src/index.ts at af5c15a, verified with bun test locally (Bun 1.4.2, Linux). Not a live Discord repro.

Steps to reproduce

1. /watch link:<valid BMS movie link> date:any days:weekend
2. The watch is created, no error.
3. /list shows it with no day filter.

Also: /watch … days:fri,xyz creates a watch filtered to Friday only — the xyz is dropped silently.

Expected behaviour

/watch rejects a days: value it can't fully read and says so, the way after: / before: already do (added in #84, with the rationale "a watch that quietly ignores 'after 18:00' fires at 10am and looks broken"). No watch is saved.

Actual behaviour

normaliseDays keeps whichever comma-separated tokens are real weekday abbreviations and discards the rest. When none survive it returns null, which cmdWatch can't tell apart from "no days: given", so the watch is saved unfiltered. When some survive, the watch is silently narrowed to just those.

days is a free-text autocomplete option (src/register.ts), so any string reaches the handler.

Bot logs

n/a — nothing is logged; that's the bug.