perf(cdclient): read ComponentsRegistry, ItemComponent and Objects from the fdb

The world and master servers pass the client's res/cdclient.fdb to
CDClientManager. When it opens, these three tables, all looked up by
their first column, find rows through the fdb's buckets instead of each
process caching the whole table: ComponentsRegistry keeps nothing,
ItemComponent and Objects keep only the entries asked for (their API
returns references). Ids whose rows CDServer.sqlite changes are loaded
from SQLite at startup and win. Without an fdb (or with one whose
columns don't match) the tables load from CDServer.sqlite as before.

ItemComponent and Objects now fill entries from one template for both
sources instead of copies of the same field list.

Tests cover the SQLite changes on top of the fdb, the no-fdb and
unmapped paths, and, when DLU_CLIENT_RES points at a client, every id of
the three tables through the fdb against CDServer.sqlite.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dDatabase/CDClientDatabase/CDClientManager.h

@@ -3,11 +3,18 @@
 
 #define UNUSED_TABLE(v)
 
+#include <filesystem>
+
 /**
  * Initialize the CDClient tables so they are all loaded into memory.
  */
 namespace CDClientManager {
-	void LoadValuesFromDatabase();
+	/**
+	 * @param fdbPath The client's cdclient.fdb. When it opens, the tables looked up by their first
+	 * column read their rows from it (shared between processes) instead of caching them. Empty, or
+	 * a file that doesn't open, keeps every table on CDServer.sqlite.
+	 */
+	void LoadValuesFromDatabase(const std::filesystem::path& fdbPath = {});
 	void LoadValuesFromDefaults();
 
 	/**