Add rename-user SQL template; make batch transaction handling robust against non-Postgres backends

- New 'rename-user' template (templates / template rename-user <old> <new>):
  best-effort uid rename across core tables (oc_users, oc_preferences,
  oc_group_user, oc_group_admin, oc_ldap_user_mapping, oc_share, oc_mounts,
  oc_storages). Explicitly NOT a supported Nextcloud operation - the
  generated script carries an in-line warning (as leading SQL comments)
  that app-specific tables (Talk, Calendar, Contacts, Mail, 2FA/WebAuthn...)
  are not covered and that the data directory must be renamed on disk
  manually, followed by occ files:scan --all. Documented the same caveat
  in both READMEs.
- Hardened the round-2 transaction wrapping: beginTransaction()/commit()/
  rollBack() are now wrapped in try/catch. PostgreSQL (our backend) has
  fully transactional DDL so this wasn't actually broken here, but
  Nextcloud also supports MySQL/MariaDB via the same IDBConnection, where
  DDL implicitly commits - on that backend a DDL statement in the batch
  would make a later commit()/rollBack() throw 'no active transaction'
  and previously that exception was unhandled (HTTP 500 instead of a
  clean JSON response). Now: if rollBack() itself fails after an error,
  we report rollbackFailed+warning instead of falsely claiming rolledBack,
  since earlier statements in that batch may already be permanently
  applied. If commit() fails with nothing to commit (already
  auto-committed), that's logged only, since the effects are already
  durably persisted.

README.md

@@ -68,6 +68,15 @@ you are about to run, ideally against a non-critical row/user first.
 - The application is not a real interactive terminal and does not support long running tasks. 
 So if your instance is pretty big, commands like `occ files:scan` will time out and fail.
 - Do not use `occ maintenance:mode --on`, obvious...
+- The `rename-user` SQL template is **best-effort only**: renaming a Nextcloud
+  username is not an officially supported operation. It updates the core
+  tables it knows about (`oc_users`, `oc_preferences`, `oc_group_user`,
+  `oc_group_admin`, `oc_ldap_user_mapping`, `oc_share`, `oc_mounts`,
+  `oc_storages`), but does **not** touch app-specific tables (Talk, Calendar,
+  Contacts, Mail, two-factor/WebAuthn, etc.). You must also manually rename
+  the user's data directory on disk (`data/<old> -> data/<new>`) with the web
+  server stopped or in maintenance mode, then run `occ files:scan --all`.
+  Back up the database first and test on a non-critical account.
 
 ## Deploying updates