Feature/1035 lua delete

[nagisml]

Summary

Lua macros can now delete caches and their rows, keeping the database consistent with the GUI delete.

Merge order: this branch is based on feature/lua-cache-write and must be merged after #1080. Until then the diff here also shows #1080's commits.

Closes #1035

Changes

New macro functions (behind the lua-macro-write flag; they need the same per-macro write permission as opensak.update()):

Function	Deletes	Returns
opensak.delete(code)	a cache with its logs, waypoints, attributes, trackables and user note	false if not in the database
opensak.delete(codes)	the same for a list, e.g. opensak.delete(opensak.codes())	number deleted
opensak.delete_log/waypoint/attribute/trackable(id)	one row; the cache's counts and log dates are recalculated	false if no such row

opensak.sql_write() allows DELETE on the cache tables (caches, logs, waypoints, attributes, trackables, user_notes):

• The schema's foreign keys have no ON DELETE CASCADE. A temporary BEFORE DELETE ON caches trigger deletes a cache's rows first, so there is no schema change, no migration and no FOREIGN KEY constraint failed error.
• AFTER DELETE triggers on the child tables record the cache, so its counts and log dates are recalculated after the statement. Inside a transaction that happens at the commit or on opensak.resync().
• INSERT OR REPLACE on a cache now replaces it and its rows. It used to be refused.

Consistency and safety

• Deletes take part in opensak.transaction() and are undone with it, including nested transactions.
• The GUI uses the existing caches_removed() host hook, which reloads the list and map and clears the detail panel when the macro ends.
• At the end of a run the macro output reports what was deleted, e.g. opensak: 3 caches deleted from database 'X'. Deletes a transaction undid are not counted.

Refactoring: the main window's bulk delete and move_caches had the same delete code copied. Both now use db/cache_delete.delete_caches(), like the macro functions.

Decisions on the open questions in #1035

1. Separate confirmation for cache deletes: no. The existing write permission (Deny / Until OpenSAK closes / Always) covers deletes.
2. Bulk delete without SQL: yes. opensak.delete() accepts a list of codes.
3. GC codes stored elsewhere: none. Only the six cache tables reference caches.
4. Deleting the cache selected in the GUI: the selection is cleared, as after moving caches.

Correction to the issue: the touched-cache triggers did not record deletes before. The delete triggers only refused them. This PR adds that recording.

Docs

The API registry and the "Changing caches" and "Logs, waypoints, attributes and trackables" sections are updated. docs/macros/api.md and the Lua stub are regenerated by the Macro API docs workflow after the merge.

Tests

• New tests/unit-tests/test_macro_delete_1035.py (24 tests): the cascade with no orphaned rows, list deletes, child-row deletes and recalculated counts, SQL deletes, INSERT OR REPLACE, transaction commit and rollback (nested too), the GUI notification, the end-of-run report, write permission, and the refusal paths.
• Existing tests adjusted where they relied on DELETE being refused. The flag test now also covers the delete functions.
• Full unit suite: 6005 passed, 108 skipped.

[AgreeDK]

Thanks @nagisml — the delete functions themselves look good. Logs, waypoints, attributes, trackables and the user note are cleaned up, deletes roll back with opensak.transaction(), the end-of-run summary reports them, and sharing db/cache_delete.delete_caches() with the GUI bulk delete is a nice cleanup.

Requesting one change: INSERT OR REPLACE. Before this PR it was refused. Now it deletes the cache's logs, waypoints, attributes, trackables and personal note, then inserts a fresh row, and (per test_sql_insert_or_replace_replaces_the_cache_and_its_rows) it isn't reported as a delete. Many people use INSERT OR REPLACE as an "update or insert", GSAK users included. A macro meant to change one field would silently wipe a cache's data, and personal notes can't be recovered from a GPX.

Could we keep refusing REPLACE (including REPLACE INTO and ON CONFLICT REPLACE) with an error pointing to INSERT ... ON CONFLICT(gc_code) DO UPDATE SET ...? That's a real upsert, and it already goes through the existing INSERT/UPDATE authorizer.

Question: macros can delete (and update) locked caches. Locking means "protect from import", so this may well be intended — but I'd like it to be a deliberate decision and mentioned in the docs.

This PR is stacked on #1080, so I'll merge it after that one.

[nagisml]

@AgreeDK realigned branch on the lua write branch

• INSERT OR REPLACE: Good catch, thanks. Changed as suggested: sql_write now refuses REPLACE before the statement runs. That covers INSERT OR REPLACE, REPLACE INTO and ON CONFLICT REPLACE, and also UPDATE OR REPLACE, which can delete a conflicting row the same way. The error points to INSERT ... ON CONFLICT (gc_code) DO UPDATE SET ....

The authorizer doesn't report the conflict resolution, so this is a keyword check that skips comments, strings and quoted names. The replace() function still works. The schema has no ON CONFLICT REPLACE constraints, so the keyword forms are the only way in.

The old test now expects all forms to be refused and checks that the cache, its logs and its note are untouched. A new test shows the ON CONFLICT ... DO UPDATE upsert keeps the child rows. The sql_write API docs mention the refusal and the alternative.

• Lock: Yes, that's deliberate. The lock flag protects a cache from being overwritten by an import, and that's all it does. Macros are something the user runs on purpose, with write permission they granted, so they can update and delete locked caches the same way the GUI can. A full lock that also blocks macro writes and deletes could be added if users ask for it. It would have to be enforced in every write path (update(), the child writers, delete(), and the authorizer and triggers for sql_write), so I'd rather not add that complexity without real demand.

I'll add a note to the docs for delete(), update() and sql_write saying the lock only protects against imports and doesn't stop macro changes.