feat: add move_to/copy_to to Files resource #83

[andrii-novikov]

Applicable issues

• fixes Add copy/move support to the Files resource #83

Description of changes

Adds move_to and copy_to methods to both Files (sync) and AsyncFiles (async), wrapping DIAL Core's resource-operations endpoints:

• POST /v1/ops/resource/move
• POST /v1/ops/resource/copy

Both methods accept source / destination as str | PurePosixPath (relative, absolute, or my_files_home() / ...) and an optional overwrite: bool = False. URL normalization and same-resource-type validation come for free via the existing DialStorageResourceMixin.get_api_path() — passing a non-files URL raises InvalidDialURLError. Errors fall through the existing _files_error_processor (412 → EtagMismatchError, 404 → ResourceNotFoundError, everything else to a generic DialException).

Naming note: the issue's sketch used move / copy, but copy collides with Pydantic's BaseModel.copy() (inherited via DialStorageResourceMixin). Renamed to move_to / copy_to for symmetry and to avoid silently shadowing the base method.

Return type is None. The OpenAPI spec only promises 200 OK with no documented body schema; if a future verification against a live deployment shows a body is returned, the cast_to=NoneType can be swapped without changing the call site shape.

Out of scope:

• Generic ops.resource resource (rejected in the issue in favor of Files-only).
• subscribe endpoint (tracked separately in Support resource subscribe  #21).

Checklist

• Title of the pull request follows Conventional Commits specification

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.