webdavfile: mkcol's 409 handling may treat 'missing parent' as 'already exists'

Follow-up from review on #24 (feat(backend): add create-folder action node).

CreateFolder calls the pre-existing mkcol helper unchanged, which treats both 405 and 409 as "already exists, treat as success." Per RFC 4918 §9.3 (WebDAV MKCOL), these mean different things:

• 405 ("MKCOL can only be executed on an unmapped URL") is genuinely "already exists."
• 409 ("a collection cannot be made at the Request-URI until one or more intermediate collections have been created") means the opposite — the parent doesn't exist yet, and the folder was not created.

If oCIS follows the spec here, mkcol currently swallows that failure silently and reports success.

This is pre-existing code, not introduced by #24, but two things make it newly relevant now that createFolder is a first-class user-facing action:

• The codebase's own Comment() method — right above mkcol in the same file — already works around exactly this by calling mkcol(".workflows") then mkcol(".workflows/comments") as two explicit, ordered calls, rather than relying on one call to create a nested path. That pattern only makes sense if the author already knew MKCOL doesn't auto-create intermediate collections.
• createFolder's own example usage is a nested path (/Archive/{{llm.output}}), and any path more than one level deep where the parent doesn't already exist would plausibly hit this case. The existing TestCreateFolderTreatsAlreadyExistsAsSuccess test bakes the 405-and-409-are-equivalent assumption in against a hand-written fake server — it can't tell us whether that assumption matches real oCIS behavior.

Action item: verify directly against a real oCIS instance whether MKCOL against a path with a missing intermediate parent actually returns 409. If so, either:

• (a) stop treating 409 as success and surface it as a real error telling the user to create the parent first, or
• (b) make CreateFolder create each path segment in turn (mirroring Comment's own pattern) so multi-level paths work as users would expect.

Start by locating CreateFolder, mkcol, Comment, and TestCreateFolderTreatsAlreadyExistsAsSuccess. Verify MKCOL behavior against a real oCIS instance when an intermediate parent is missing, then determine which behavior the project should adopt. Update the implementation and tests so the result distinguishes an existing collection from a missing parent, and confirm the nested-path example is covered.