/**
* @mainpage Relational NT
*
* @image html logo.png
*
* Relational NT is an experimental database kernel inspired by the
* object-management model of the Windows NT kernel. The project applies
* explicit object management to database state: relations, tuples,
* transactions, namespaces, permissions, cursors, and handles are
* runtime-managed objects rather than isolated subsystems.
*
* @section motivation Motivation
*
* The NT kernel is a good model for a dedicated database kernel for three
* reasons.
*
* **The object manager.** NT's OB gives every kernel resource a named path,
* a security descriptor, and a uniform open/close lifecycle enforced through
* handles. A database kernel has the same requirements. Rather than building
* those mechanisms independently for each database concept, this project
* borrows the NT object manager's shape directly.
*
* **Physical backends as drivers.** NT device drivers expose a narrow
* dispatch table. The kernel routes I/O through it without knowing whether
* the device is a local disk or a network adapter. Storage backends here
* follow the same pattern. A remote backend like etcd is just another
* driver, but brings its own concerns: network latency, connection
* management, and the possibility of partial failure. The driver boundary
* keeps those concerns inside the backend module.
*
* **Clients as environment subsystems.** NT supports Win32, POSIX, and OS/2
* as environment subsystems layered above a common native API. A database
* client works the same way: a PostgreSQL wire adapter, a MySQL wire
* adapter, or an HTTP/JSON interface each translates its protocol into
* kernel-level operations. The kernel never sees SQL syntax or protocol
* framing.
*
* @section architecture Architecture
*
* - ObjectManager registers, locates, and references database objects by
* logical path.
* - PermissionsManager keeps capability checks separate from object lookup.
* - IdentityManager decides whether an object supports a requested lifecycle
* operation.
* - LifecycleManager models monitoring, pinning, cleanup, and contention.
* - HandlerManager orchestrates the full open/close workflow and owns handle
* allocation.
* - CursorManager provides a pull-based iterator over storage, abstracting
* pagination, snapshot pinning, and scan boundaries.
* - VM separates terminating first-order relational retrieval (Tarski) from
* higher-order logic execution (Karuta).
* - NamespaceReferenceManager handles logical path mapping and namespace
* isolation, including private branch shadowing and atomic multi-reference
* updates.
*
* @section building Building
*
* Requires MSVC, CMake 3.10 or later, and vcpkg. Dependencies are fetched
* automatically during configure.
*
* @code{.sh}
* cmake --preset x64-debug
* cmake --build out/build/x64-debug
* @endcode
*
* A release build uses @c --preset @c x64-release.
*
* @section docs Generating Documentation
*
* @code{.sh}
* doxygen Doxyfile
* @endcode
*
* Generated HTML is written to @c docs/generated/html.
*/
/**
* @namespace nt
* @brief Contains the Relational NT runtime managers and API facade.
*/
