fix(create): roll back only the database and user this create made

[mrrobot47]

Depends on EasyEngine/site-command#503 and must be merged after it: this uses its new reserve_global_db_names() and check_site_name_conflicts().

This is a guard against rare name collisions and mistakes, not something a normal ee site create --type=wp runs into. It only matters when two site names map to the same database name or docker volume prefix, when --dbname/--dbuser names a database or user that already exists, or when a --ssl=custom check fails while such a collision exists. In those cases a failed create's rollback could drop the other site's database or user.

When it happens

• Colliding default DB names: a-b.test and a.b.test both map to a_b_test, so the second create fails and its rollback drops the first site's database.
• A taken --dbname or --dbuser: the create fails and the rollback drops that database or user.
• A failed --ssl=custom check (for example a typo in --ssl-key): it fails before any database work, even with --local-db, but the rollback still dropped the global database with the site's default name. The same rollback also removed a sites/<site> directory that already existed.
• Colliding volume prefix or compose project (a-b.test / ab.test, blog.example.com / blogexample.com): the second site used the first site's volumes and containers.

What changes

• The rollback (catch_clean() and the signal handler) drops the database and user only when this run created them on the global DB.
• The global DB names go through reserve_global_db_names() before anything is created.
• The webroot, volume and compose project checks (check_site_name_conflicts()) and the --ssl=inherit with --mu=subdom/--wildcard check now run before the database step, so these refusals no longer leave a global database and user behind.
• Level 0 lasts until the webroot exists, so an early failure keeps a directory this run did not create.
• An interrupted create (for example Ctrl+C during the database or webroot step) now rolls back the database, user and webroot it had just made, instead of leaving them behind.

Behaviour changes

• A taken --dbname or --dbuser is refused with a clear error. Such a create never succeeded before either.
• A taken default DB name gets a _2 (then _3, …) suffix, stored in the site row as before. Default names are cut to 64 characters.
• A site whose volume prefix or compose project collides with another site's is refused before anything is created.
• Existing sites, including pairs that already collide, are untouched.

Testing

• A harness that runs the real code against a simulated docker and DB, on PHP 7.4 and 8.5: every case reproduces on develop and passes with the fix.
• A live host run of each case with the nightly and with a phar built from these branches: the nightly shows the problem, the fix refuses or rolls back cleanly. Normal WP creates (--cache, --local-db), clone and delete work as before.
• Tested live on a host with the final branch: the full collision matrix, an interrupt at each create step, and regular creates and deletes all behave as expected.