Close Database Engines Before Cloud Sync #2974

Is there an existing issue for this?

• I confirm that I have not found an existing or similar issue.

Description

## Problem

External database engines return false from holdsFileLocks() because their
primary database is remote. However, they can still own a local H2 modification
audit database.

Uploading the engine directory while H2 modifies or compacts that audit file
can leave the Azure/Netty chunked uploader reading beyond the file's new end.
This creates a zero-progress CPU loop and stalls other cloud-storage requests.

## Fix

• Treat every DATABASE engine as requiring closure before pushEngine.
• Remove and close the engine before synchronizing its directory.
• Record whether the engine was removed rather than calling
  holdsFileLocks() again after closure.
• Reopen the engine after successful or failed synchronization.
• Always release the engine synchronization lock.

## Tests

• External database without primary file locks is closed before upload.
• Database is reopened after synchronization.
• Non-database engine without file locks remains open.
• Failed transfer still reopens the database and releases the lock.

## Operational impact

Database pushes briefly close and reload the database engine. No database
schema, audit schema, deployment configuration, or primary data is changed.

Relevant Feature or Code

No response

Requirements (what)

No response