[Feature]: Extract WebDAV into a dedicated workspace crate

[AptS-1547]

Problem

AsterDrive's WebDAV implementation currently lives under src/webdav/ inside the main application crate. It now contains protocol parsing, DAV path handling, HTTP response construction, lock-token semantics, property namespace rules, filesystem adapters, database-backed locks, storage access, authentication, workspace scope handling, and audit integration.

That layout has served the current product, but it makes the ownership boundaries difficult to enforce:

• protocol behavior and AsterDrive product adapters are compiled and reviewed as one application-local module;
• reusable DAV contracts and pure protocol logic are harder to test without bootstrapping PrimaryAppState;
• future WebDAV client compatibility work risks adding more application-specific branches to the protocol handlers;
• the current module is difficult to consume from sibling binaries, compatibility tools, or a focused protocol test harness;
• moving files mechanically would create a large dependency cycle instead of a useful crate boundary.

The current business model must remain explicit during this work: WebDAV paths resolve to AsterDrive file/folder entities, dead properties are stored in entity_properties by entity_type + entity_id, and .DAV is an ordinary user directory rather than a reserved metadata path.

Parent roadmap: #421

Proposed solution

Create a dedicated workspace crate under crates/ for the WebDAV protocol boundary, tentatively named aster_drive_webdav.

The extraction should be staged around ownership rather than directory movement:

1. Inventory the current src/webdav/ modules and classify each function as protocol core, product adapter, persistence, storage, authentication, or observability.
2. Move pure and contract-oriented pieces first: DavPath, depth and If parsing, destination validation, XML/protocol response helpers, DAV property and lock models, and protocol-level error mapping.
3. Define explicit traits for the application-owned boundaries: resolved file/folder entities, workspace scope, storage reads/writes, property repository access, lock persistence, WebDAV account authentication, audit events, and runtime limits.
4. Keep the AsterDrive adapter implementation close to the product services and repositories. The crate should consume capabilities through traits instead of importing SeaORM entities, PrimaryAppState, or concrete storage drivers directly.
5. Migrate resource handlers incrementally while preserving the current Actix route entrypoint and response behavior. The final application layer should be a thin protocol adapter plus AsterDrive capability wiring, not a second WebDAV implementation.
6. Keep product semantics explicit in the crate contract: entity_properties remains the property store, DAV: and system.* remain protected namespaces, and no directory name becomes an implicit internal metadata boundary.

The crate name, public module layout, and trait granularity should be finalized after the dependency inventory. Avoid introducing a generic WebDAV abstraction that hides AsterDrive workspace, storage policy, quota, audit, and lock semantics.

Acceptance criteria

• A dedicated WebDAV crate exists under crates/ and is a workspace member with documented ownership boundaries.
• Protocol-core tests run without constructing the full AsterDrive application state.
• AsterDrive's adapter layer remains authoritative for workspace scope, entity resolution, properties, locks, storage, authentication, and audit behavior.
• No duplicate protocol implementation exists between src/webdav/ and the new crate after migration.
• The existing Actix WebDAV entrypoint, authentication contract, status codes, XML bodies, lock-token behavior, and path semantics remain compatible.
• Litmus 0.18 basic, copymove, props, locks, and http continue to pass their strict baseline.
• protected remains an explicit security-policy probe: its .DAV differences are recorded as observed product-model differences and are not converted into a reserved-directory requirement.
• Full cargo test --test webdav, cargo check, and workspace formatting pass during each migration phase.
• The final crate has no direct dependency on application-global mutable state and no hidden path-to-internal-table mapping.

Alternatives considered

• Keep all WebDAV code in src/webdav/: lowest immediate churn, but the current ownership and test-boundary problems remain.
• Move only the parser and response helpers: useful cleanup, but too shallow to establish a real protocol/application boundary.
• Adopt a generic WebDAV server crate as the product boundary: this would obscure AsterDrive's workspace scope, storage policy, entity properties, lock persistence, audit, and failure semantics.
• Move every existing file into one new crate mechanically: likely to create dependency cycles and preserve the current coupling under a different path.

Category

Other

Contribution

• I am willing to help implement this feature
• I can help test and provide feedback

Checklist

• I have searched existing issues for similar requests

Current implementation status (2026-07-25)

This section supersedes the original proposal and acceptance criterion requiring a new WebDAV crate inside the AsterDrive workspace.

• Outdated: creating crates/aster_drive_webdav as an AsterDrive workspace member.
• The protocol boundary now lives in the AsterForge workspace as aster_forge_webdav; AsterDrive consumes that crate and keeps the product-owned authentication, workspace scope, entity resolution, persistence, storage, audit, and runtime policy adapters.
• Protocol-core tests belong to aster_forge_webdav and run without constructing AsterDrive application state. AsterDrive retains adapter/integration tests, real-client tests, and the pinned Litmus 0.18 compatibility gate.
• The corresponding acceptance criterion should therefore be read as: a dedicated WebDAV protocol crate exists in the AsterForge workspace with documented Forge/Drive ownership boundaries.