Adds file move operation and startup robustness

[adriy-be]

Description of the changes you made :

• Implements a file move operation:
  • Introduces move methods across DirectFileManipulator, LiveSyncLocalDB, and EntryManager.
  • Provides moveDBEntryByPath in EntryManagerImpls to handle database-level moves, including case-only renames, overwrites, and marking source entries as deleted.
  • Includes unit tests for the moveDBEntryByPath functionality.
• Enhances DirectFileManipulator initialization and shutdown:
  • Wraps the init process in a try...catch block to ensure the ready promise correctly resolves or rejects, improving startup error handling.
  • Sets default no-op handlers for api.addLog and a default vault name for api.getSystemVaultName during early startup to prevent potential runtime errors from unassigned API handlers.
  • Adds a controlled shutdown mechanism in the close method, attempting to use a control service's onUnload hook before falling back to direct database shutdown.

[adriy-be]

It's a feat for https://github.com/fanselau/obsidian-vault-cli
Implemented in my fork: https://github.com/adriy-be/obsidian-vault-cli/tree/move

[vrtmrz]

Thank you for your PR! This is a minor point, but let me clarify something.
Regarding this move operation, was it really necessary? The reason I ask is that put and delete actually handle quite a few different scenarios (such as what to do if a conflict arises or is resolved by deletion). In this instance, I suspect that delete followed by put would have sufficed.

Incidentally, as you can see from the watchVaultRename method in StorageEventManager, I have no particular objection if you simply add the move to DirectFileManipulatorV2 as a utility function without changing LiveSyncLocalDB!