v1.1.1

fix(db): serialize display-id allocation and make set_* helpers atomic

Under concurrent agents — the workload Sara is built for — three data-integrity
bugs were reachable:

* insert_task read the next free display ID and inserted it as two separate
  steps. WAL readers never block, so racing agents all read the same value and
  all used it: 40 parallel `sara add` calls on 1.1.0 produced 9 distinct IDs,
  31 tasks sharing ID 8. tasks.id has no UNIQUE constraint, so nothing caught
  it and `sara done <id>` became silently ambiguous. The same race applied to
  memory labels (insert_item), checklist positions (add_step) and repack_ids.
  Allocation now holds the write lock (BEGIN IMMEDIATE) across read and write.

* The set_item_*/set_task_files_sourced helpers DELETE then INSERT in a loop
  with no transaction, so a mid-loop failure committed the delete and lost the
  data. Each is now atomic via SAVEPOINT — savepoints nest, which matters
  because import already holds a transaction open.

* relearn --file stored the path raw while learn and recall both resolve it to
  absolute, so a corrected memory silently vanished from recall --file.

add_step also swallowed DB errors and fell back to position 1, inserting at the
front of the guide with a duplicate position instead of reporting the failure.

Each fix is covered by a test verified to fail without it.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>