Procmon 4.11: ring-buffer whole-file size limits and complete event retention

The Microsoft-signed x64 Procmon 4.11 build under review is SHA256 fc3af5317c707e0555ad6e7590ad65ceb5c5085b053b41221944ac3ca3492d9c. Its embedded usage documents ring-buffer size in MB, a time limit in minutes, virtual-memory capture and a Runtime option. A synthetic file-backed capture observed 134217728 bytes of running logical PML length; it later settled to 491056 bytes. The cause is not established. Our unchanged requirements are 33554432 bytes per PML and 134217728 bytes aggregate, based on logical file length throughout capture/save, plus complete stored-event and process-metadata inspection across the full 15-second test interval.

1. Does ring-buffer size bound the entire on-disk PML logical length, or only event storage? What are the exact MB units, minimum setting, rounding/growth quantum and possible startup/finalization overshoot for this build?
2. Are process metadata, indexes, headers and any companion/temporary files inside that limit? Can a supported configuration keep every PML at or below 33554432 bytes throughout creation, capture, finalization and native save?
3. How can a native audit establish that no event was discarded or overwritten during the complete interval? Which native overflow/wrap indicators cover both event records and process metadata?
4. Does loading a saved native configuration override command-line ring-buffer settings? Which supported ordering binds storage controls while retaining the exact pre-existing event filters?
5. For virtual-memory capture, is there a supported bounded-duration stop and native All events PML save before normal exit, without a terminate-all call? Does that save avoid a temporary whole-file length above the same bound?

Please distinguish documented size guarantees from recommended settings or finite observations. We are not asking to raise caps, omit files, change the logical-length metric, filter exports after collection, drop old evidence or alter operating-system policy.