docs: explain timestamp collision prevention in tablespace rename

Add comment documenting why timestamp collision cannot occur during temp
tablespace rename operations on tmpfs storage.

The comment clarifies that consuming charms ensure leader-only execution and
PostgreSQL serializes operations through exclusive locks, making second-precision
timestamps sufficient for uniqueness.

Addresses feedback from PR review comment:
#54 (comment)

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>

Author: marceloneppel

single_kernel_postgresql/utils/postgresql.py

@@ -1124,6 +1124,8 @@ def _handle_temp_tablespace_on_reboot(
         if is_tmpfs(temp_location):
             # tmpfs: Directory is empty after reboot, safe to rename and recreate
             # Rename existing temp tablespace instead of dropping it.
+            # Timestamp collision is not possible: the charm ensures this code runs leader-only,
+            # and it executes within a single database transaction holding exclusive locks.
             new_name = f"temp_{datetime.now(timezone.utc).strftime('%Y%m%d%H%M%S')}"
             cursor.execute(f"ALTER TABLESPACE temp RENAME TO {new_name};")