[bug] Chemin lazy : temp tables DuckDB jamais supprimées sur une connexion fournie par l'utilisateur (+ nom de table collisionnable)

Contexte

Sur le chemin lazy, la table slim booléenne est matérialisée par dplyr::compute(cmp_slim, name = tmp_tbl_name, temporary = TRUE) (R/compare_datasets_from_yaml.R, bloc is_lazy). Deux problèmes :

1. Fuite : quand l'entrée est un tbl_lazy sur une connexion appartenant à l'utilisateur, la temp table n'est jamais droppée — elle vit jusqu'à la fermeture de la connexion. Sur un service ou une session longue faisant des comparaisons répétées, elles s'accumulent (RAM/disque DuckDB). Le chemin Arrow, lui, est propre : connexion privée fermée par on.exit(dbDisconnect(..., shutdown = TRUE)).
2. Collision de nom : tmp_tbl_name est dérivé de format(Sys.time(), "%H%M%OS3") — deux appels dans la même milliseconde (ou à la même heure-du-jour un jour différent sur connexion longue durée) produisent le même nom → compute() échoue.

Reprex

library(datadiff); library(duckdb); library(dplyr); library(DBI)

con <- dbConnect(duckdb())
duckdb_register(con, "ref",  data.frame(id = 1:3, x = 1:3))
duckdb_register(con, "cand", data.frame(id = 1:3, x = 1:3))

for (i in 1:3) {
  invisible(compare_datasets_from_yaml(tbl(con, "ref"), tbl(con, "cand"), key = "id"))
}

dbGetQuery(con,
  "SELECT table_name FROM information_schema.tables
   WHERE table_name LIKE 'datadiff_%'")
#> 3 temp tables accumulées — attendu : 0

Critères de succès

• Après chaque appel sur connexion utilisateur, la temp table est supprimée (on.exit(DBI::dbRemoveTable(...)) ou équivalent), y compris en cas d'erreur en aval.
• Le reprex renvoie 0 table résiduelle après les 3 appels.
• Nom de table garanti unique par processus (compteur + PID/tempfile-style, plus de dérivé d'horloge).
• Test DuckDB : 2 appels successifs sur la même connexion → pas d'erreur de collision, pas de table résiduelle ; chemin Arrow inchangé (connexion privée toujours fermée).

Start in R/compare_datasets_from_yaml.R at the is_lazy block that calls dplyr::compute with tmp_tbl_name. Run the supplied DuckDB reprex and inspect the Arrow cleanup path for comparison. Done means repeated calls on one user connection leave no datadiff tables, avoid name collisions, clean up after errors, and leave the private Arrow connection behavior unchanged.