GH-1084: Honor dontUseContainerParents for checkExists and namespace mkdir

[arimu1]

checkExists().creatingParentContainersIfNeeded() ignored CuratorFrameworkFactory.dontUseContainerParents() / useContainerParentsIfAvailable. Parents were always created as CreateMode.CONTAINER, which raises Unimplemented on servers without container support (ZooKeeper 3.4.x, ClickHouse Keeper, etc.).

CreateBuilderImpl.creatingParentContainersIfNeeded() already gates container parents on that flag and still creates ordinary persistent parents when it is off. ExistsBuilderImpl now does the same. Foreground and background mkdirs also re-check the flag so the async ExistsBuilderImpl constructor path cannot send container creates either.

NamespaceImpl.fixForNamespace() had the same hole: ZKPaths.mkdirs(..., asContainers = true) was hardcoded, so the first namespaced operation issued createContainer (opcode 19) even after dontUseContainerParents(). That argument now uses client.useContainerParentsIfAvailable().

Fixes #1084 (CURATOR-565).

Closed prior attempts #352 / #353 / #354 only flipped the exists setter and did not fall back to persistent parents or cover namespace mkdir.

Tests

• TestFramework.testExistsOverrideCreateParentContainers — dontUseContainerParents() + checkExists().creatingParentContainersIfNeeded(); parents remain after the leaf is deleted (would be auto-removed if they were containers).
• TestFramework.testNamespaceOverrideCreateParentContainers — namespaced client with dontUseContainerParents(); the namespace znode remains after its child is deleted.

Local: Temurin 21, mvn -pl curator-framework -am test -Dtest=TestFramework — 50/50 pass. The two new tests failed on unfixed master (assertNotNull after container cleanup).