"Last updated by user" date — dedicated column set only by user edits (from #821)

[AgreeDK]

Background

Split out from the GSAK filter parity epic #821 (item 6, Dates tab). GSAK's
filter dialog has a last updated by user date (UserLastUpdate in GSAK) that
only changes when the user edits a cache — not when it's refreshed by an import.
OpenSAK has no equivalent today.

Current state

The Dates tab's last modified row (changed_date) maps to Cache.last_updated.
On beta, that column is only ever written by the GSAK importer
(src/opensak/importer/gsak_importer.py, from GSAK's Changed column). It is
not set by:

• GPX / Pocket Query import
• any user edit in OpenSAK

So last_updated can't stand in for a user-edit date, and in a database built
from GPX/PQ files it's empty, which makes the last modified filter match
nothing there.

Proposal

1. Add a new nullable column, e.g. Cache.user_updated_at (DateTime), with an
   Alembic migration. Existing rows stay NULL.
2. Set it to the current time whenever the user changes a cache in OpenSAK, for
   example:
   • personal note
   • user flag
   • corrected coordinates
   • child waypoints added / edited / deleted by the user
   • lock / unlock
   • marking a cache as found
   • User Data 1–4 (if editable in the UI)
3. Do not touch it on import, move between databases, or recalculation of
   distances/bearings. last_gpx_update already covers import activity.
4. GSAK import: map GSAK's UserLastUpdate into the new column if the GSAK
   database has it, so the date survives migration from GSAK.
5. Add a Last updated by user row to the Dates tab, using the same date
   operators as the other date rows. Optionally add a matching list column.

Open questions

• Scope of edits: is the list above right? Is marking a cache as found a
  "user edit" in GSAK's sense, or only direct edits of fields?
• Existing changed_date row: should GPX/PQ import fill last_updated when
  the source provides a date, or should the row be relabelled or hidden for
  databases where it's always empty?
• One central hook vs. per call site: a single helper (or SQLAlchemy event
  on the user-editable fields) is less likely to miss an edit path than setting
  the column at every call site.

Tests

• Each edit path sets user_updated_at; imports and database moves don't.
• Filter parity between SQL and Python (test_filter_sql_parity_633.py) for
  the new date row.
• Migration adds the column without touching existing data.
• GSAK import maps UserLastUpdate when present.