Investigate parallel Vulkan command-buffer recording

Read-only feasibility investigation of the main Vulkan renderer, focused on multiple command-recording workers. Trace current frame lifecycle, existing threading/command pools, draw preparation, mutable recording state and resource lifetimes. Identify reuse opportunities, correctness constraints and a small practical first experiment. No implementation or performance claim requested; discuss findings with user before changes. Acceptance: source-backed assessment with clear measured-versus-unmeasured limits and recommended next steps. Investigation complete by source inspection, no implementation or execution/performance validation. Clean feature/vulkan-multithreaded-rendering at 8de2ae24b is 13 commits behind locally recorded origin/develop d95d7f74c; no fetch, checkout or history changes. Also inspected newer Vulkan backend through temporary git snapshots: code moved into PRK.GraphicsEngine/Vulkan and renderer split into partial files; recording remains serial. Newer allocator already removes BorrowBuffer/BorrowImage lock, unlike current checkout. Existing foundations: prepared ordered DrawCommand stream, instance batching/storage, ready-resource snapshots, per-frame fences and retirement, per-thread command pools, separate shadow primary/submission (still CPU serial), resource loader and asynchronous animation. No secondary execution/inheritance implementation found in checkout. Main pass sequence is light cells, AO geometry/compute, sky probes/ripples, reflection, main world/picking, scene copy/translucency, bloom/UI/composite/readback. Required boundary: serially resolve material descriptors and pipeline variants, dirty pipeline rebuilds, batch resource slots and rewritable mesh updates; then publish stable per-frame draw packets with handles and bindings. DrawStreamRecorder mutates dictionaries, batch pipeline caches and transparent unique sets; InstanceBuilder.MaterialFor can allocate/free descriptors and retire materials; GraphicsPipeline.Bind can recreate; Mesh recording can consume/update rewritable vertices. BufferAllocator.Retire acquires main-owned LifetimeGate, so existing lazy paths on joined workers can deadlock. TranslucentSequence and BodyStyleRenderer have shared per-view planning scratch and interleave world, bodies and effects; prepare ordered plan before partitioning, do not sort per worker. Profiler CPU/GPU active state is thread-static and GPU written mask mutable; collect worker-local timings/counters and merge on owner, keep timestamp orchestration primary-owned. Recommendation for discussion: bounded persistent recording workers, worker-by-frame-slot pools/buffers recycled after parent frame fence, prepared data with no shared mutation, primary-owned render-pass/barrier/timestamp/submission orchestration. First bounded prototype: opaque/AO geometry secondaries with 1/2/4 recording lanes and deterministic range execution, leaving transparency/UI serial initially; extend only if measurements justify it. Alternative coarse pass primaries reuse inline render-pass methods but have weaker balancing and reflection depends on quality/scene. Keep GPU order/dependencies unchanged; CPU recording parallelism is not GPU async queues or simulation/render pipelining. Validate old serial vs prepared serial vs secondary single-lane vs multi-lane, matched reversed controls, headless real Vulkan sync/thread checks, visual/counter/picking equivalence, dynamic vertices, resource reload/retirement, resize/shutdown and worker failure. No speedup estimate established.