Enable DTZ ruff rule set (flake8-datetimez)

[aevri]

Add "DTZ" to ruff lint extend-select to enforce timezone-aware datetime
usage. Fix DTZ005 violations by passing tz=datetime.UTC to
datetime.now() calls used for relative age comparisons. Suppress DTZ007
violations with noqa comments where strptime parses legacy filename
formats without timezone info.

https://claude.ai/code/session_01ENWUz3LNWSDahEfcQeii1h

[aevri]

/review

[claude]

PR Review: Enable DTZ ruff rule set (flake8-datetimez)

Clean, well-scoped PR. A few observations:

Looks Good

• Consistent approach: datetime.now() calls and parsed datetimes are all made UTC-aware together, so comparisons (e.g. calc_last_micro_age_days, pick_comparison_path) won't raise TypeError from mixing naive and aware datetimes.
• Reasonable noqa for cmd/status.py: The strptime result is only used for date validation, not arithmetic, so suppressing DTZ007 there makes sense.
• pyproject.toml change is minimal and well-documented with the comment.

Suggestions

1. Semantic accuracy of UTC for parsed datetimes: In mel/lib/datetime.py and mel/micro/fs.py, .replace(tzinfo=datetime.UTC) stamps UTC onto datetimes parsed from filenames that have no actual timezone information. This is technically a lie -- the filenames likely represent local time. It works fine today because these datetimes are only compared against each other or against datetime.now(tz=datetime.UTC) for relative age (day-granularity), so the constant offset cancels out. But it could be surprising to a future reader or cause subtle bugs if these datetimes are ever displayed or compared against truly UTC timestamps. A short comment on one of the .replace() calls would clarify the intent.

2. Docstring update in mel/lib/datetime.py: The docstrings for guess_datetime_from_path and guess_datetime_from_string still say :returns: datetime.date if successful and :returns: datetime.datetime if successful -- now they always return timezone-aware datetimes. A one-line note like Returns a timezone-aware (UTC) datetime would be helpful. (The doctest expected output is updated, which is good.)

No Issues Found

• No mixing of naive/aware datetimes across call sites (mel/lib/common.py only does max() on returned values, which is fine since they are all consistently UTC-aware now).
• No security or performance concerns.
• Existing test in datetime__t.py still passes since guess_datetime_from_string returns non-None regardless of tzinfo.

Overall this is a clean change. The suggestions above are minor polish -- the PR is correct as-is.