Rendering fireEngine’s first triangle

This release completes fireEngine’s first rendering path. The application now keeps its window open, records and submits graphics commands, and presents a coloured triangle using Vulkan 1.4 dynamic rendering.

A new Renderer class encapsulates frame acquisition, command recording, queue submission, and presentation while leaving the platform event loop in main.cpp. Each frame waits for its previous submission, acquires a swapchain
image, recycles the frame’s command pool, records the draw, and submits it using Synchronization 2.

Vertex and uniform data are now backed by a reusable AllocatedBuffer abstraction built on Vulkan Memory Allocator. The triangle vertices are uploaded once, while each frame slot owns an identity-transform uniform buffer that is
supplied to the vertex shader through a Vulkan 1.4 push descriptor.

Swapchain synchronization now covers the complete rendering sequence. Image layout transitions are ordered with the image-available and render-finished semaphore scopes, and presentation waits on the semaphore belonging to the
acquired swapchain image. Rendering distinguishes clean presentation, successful-but-suboptimal presentation, and an out-of-date swapchain so successfully presented frames are always counted correctly.

Included in this release

• A persistent GLFW event loop in main.cpp.
• A Renderer owner for command recording, submission, and presentation.
• A VMA-backed AllocatedBuffer abstraction.
• Host-writable vertex and per-frame uniform buffers.
• Upload and binding of a coloured triangle.
• Push-descriptor binding of the frame transformation matrix.
• Vulkan 1.4 dynamic-rendering command recording.
• Synchronization 2 image-layout transitions.
• Correct semaphore stage scopes for acquisition and presentation.
• One render-finished semaphore selected by acquired swapchain image.
• Three-state presentation results for clean, suboptimal, and out-of-date paths.
• Correct frame accounting when a suboptimal image is successfully presented.
• Explicit handling of swapchain changes without attempting recreation yet.
• Exception-safe cleanup of submitted renderer resources.
• A --frames option for bounded automated runs.
• CTest coverage that renders and presents a complete frame.
• Expanded documentation covering synchronization and presentation-resource lifetimes.
• Project version updated to 0.6.0.

Swapchain recreation remains deliberately separate. If the surface becomes out of date or suboptimal, the application reports the change, performs its conventional shutdown wait, and exits. A later release can move the remaining
Vulkan ownership behind Renderer and introduce safe replacement and retirement of format-dependent presentation resources.