fix: ActivitiesCard crashes — t() in a prop default has no scope

[everysingletear]

ActivitiesCard takes its title as ({ title = t('activity.title') }).
A default parameter is evaluated in the function's own scope, where t
does not exist: the only t in the file is bound inside ActivityItem,
a separate component. Sidepanel renders the card without a title, and
activities is enabled: true in DEFAULT_SIDEPANEL_CONFIG, so the
default is always evaluated on a desktop-width screen.

The hook moves into the component body and the title falls back there
instead. Same rendered output; three render sites now read displayTitle.

This is my regression: it arrived with #216, which described itself as
"no behaviour change". It was not caught because a bundler cannot flag it
— an unbound t is indistinguishable from a global — and my checks only
verified that keys and imports existed, not that t was in scope. It is
visible in the built bundle: ({title:e=t("activity.title")}) keeps the
literal t because the minifier cannot rename a free variable, while a
working call nearby minifies to q=e("common.confirm").

I have added an eslint no-undef pass to my own pipeline and run it
before sending anything from now on.

How to see it

Sidepanel renders the card without a title, and activities is
enabled: true in DEFAULT_SIDEPANEL_CONFIG, so any logged-in user on a
screen wider than lg hits it.

It is also visible without running anything. Build develop and grep the
bundle:

grep -o '.\{50\}activity\.title.\{15\}' dist/assets/Application-*.js
→ OAe=({title:e=t("activity.title")})=>{const[n,

The translator is the bare letter t — the minifier cannot rename a free
variable, so it leaves it as written. A working call a few lines away
minifies to q=e("common.confirm"), where e is the bound t from the
enclosing hook. That difference is the whole bug.

[everysingletear]

Added a second fix to this PR — same root cause, found while rebasing my
remaining branch onto develop after #210 landed.

ChoresOverview.jsx does not parse at all. #210 put a useTranslation
call inside a module-level object literal:

const CHORE_STATUS = {
  const { t } = useTranslation('chores')
  NO_DUE_DATE: 'No due date',

It doesn't break the build because nothing imports that file, so vite never
compiles it — which is exactly why neither of us noticed. It does break
eslint and editors, and it would break the moment the file is wired up
again.

So that's two defects from my extraction PRs: a runtime crash from #216 and
a syntax error from #210. Both share a cause — the hook was inserted
mechanically and nothing downstream ever parsed or ran the result — and both
are caught by the no-undef pass I now run, which reports the parse error
as well as the undefined t.

I'd rather you knew the count than found the second one yourself later.

[meauxt]

Thank you