ESENT durable commit: log namespace and application-created directories on NTFS

I am assessing the supported durability contract for an offline Windows application using the in-box ESENT engine on local NTFS, from a non-administrator account. This is a documentation question; no data-loss bug is being alleged.

Assume supported Windows 11, a correctly configured storage stack that honors flush/write-through requests, recovery/logging enabled, no lazy commit, and a successful outermost JetCommitTransaction. Hardware that falsely acknowledges persistence, media destruction and administrator tampering are outside scope.

The ESE transaction documentation promises persistent acknowledged commits, and the file-lifecycle documentation describes log rollover. I understand those guarantees to cover engine-managed rollover under supported configuration. Please confirm whether the application owes any extra namespace synchronization beyond successful documented ESE calls; I am not seeking a separate proof of each internal rename.

My unresolved bootstrap question is that JetCreateDatabase normally requires an existing directory. When the application has just created that directory and any ancestor directories, what supported non-administrator API sequence durably establishes the complete containing directory chain before the first committed transaction is relied on? Does ESENT cover this, or must the application establish it independently?

Please identify the documented APIs/configuration and supported Windows/ESENT versions. We cannot rely on privileged volume flushes or private JET APIs. A process-restart test alone is not being treated as a power-loss guarantee.

References: ESE transactions, JetCreateDatabase, FlushFileBuffers.