Replace runtime `item.path` and `album.artpath` consumers

Part of: #1409

Depends on: model filesystem helpers accepting `Path`.

## Problem

Many runtime call sites still use `LibModel.path` and `Album.artpath` directly even when they are working with files on disk. That keeps byte-path assumptions in plugins, UI commands, importer code, and tests that should only need the Path-facing model API.

## Expected behavior

- Runtime code uses `item.filepath` instead of `item.path` for filesystem operations.
- Runtime code uses `album.art_filepath` instead of `album.artpath` for album art filesystem operations.
- `LibModel.path` and `Album.artpath` remain available only for storage compatibility and targeted byte-boundary tests.
- Plugin code passes `Path` values to path utilities, subprocess argument construction, media libraries, and event payloads when the called API accepts path-like objects.
- User-facing output remains unchanged.

## Suggested fix

Update core, UI, and plugin call sites in one pass after the model helper contract is Path-native. Keep byte-property assertions only where they intentionally document storage compatibility.

## Acceptance criteria

- Direct `item.path` and `album.artpath` use is limited to compatibility, persistence, or explicit boundary tests.
- Affected importer, UI, plugin, and library tests pass.
- No user-facing path formatting regresses.
- `poe test` and `poe lint` pass with coverage at or above 80%.

Start by locating runtime consumers of item.path and album.artpath across core, UI commands, importer code, plugins, and their tests. Read the model helper contract and inspect the affected call sites before updating them. Done means only compatibility, persistence, and explicit boundary tests use the byte properties, with poe test and poe lint passing and coverage at least 80%.

Written by the indexing model from the issue text.