Migrate artwork and media path APIs to `pathlib.Path`

Part of: #1409

Depends on: #6807 and #6808.

## Problem

Artwork and media-file helpers still carry byte-path assumptions through `ArtResizer`, `fetchart`, shared art helpers, and plugins that read, write, resize, embed, or derive artwork paths. This keeps path conversion mixed into artwork behavior and makes later runtime path migration harder to review.

## Expected behavior

- Artwork helpers use `Path` for filesystem paths.
- `ArtResizer`, `fetchart`, shared art utilities, `embedart`, `thumbnails`, and related convert/play call sites avoid caller-side path encoding.
- Tests for artwork fetching, resizing, thumbnails, and media-file path handling use `Path` wherever possible.
- Byte values remain only where an external API or persisted boundary explicitly requires bytes.
- Existing artwork behavior is preserved.

## Suggested fix

Migrate the artwork/media path surface as the first #6809 child issue, before broader library/importer/model contract changes.

## Acceptance criteria

- Artwork and media path APIs accept or return `Path` at runtime where practical.
- Existing art, thumbnail, resize, convert, play, and file tests pass.
- Remaining byte conversions are tied to explicit external or storage boundaries.
- `poe test` and `poe lint` pass with coverage at or above 80%.

Start at the ArtResizer and fetchart entry points, then trace the shared art utilities and embedart/thumbnails call sites named in the issue. Run the artwork-fetching, resizing, thumbnail, and media-file tests first; done means practical runtime paths use Path, explicit byte boundaries remain, and poe test plus poe lint pass with at least 80% coverage.

Written by the indexing model from the issue text.