Use `Path` in models while keeping SQL path storage as bytes

Part of: #1409

Depends on: runtime callers preferring `filepath` and `art_filepath`.

## Problem

The central model type still exposes path fields as byte-oriented values, while the long-term runtime contract should be `Path`. At the same time, #1409 identified that SQLite should continue storing filesystem paths as bytes so surrogate escapes and existing database contents remain safe.

## Expected behavior

- `PathType` and `NullPathType` expose `Path` values to Python model code.
- SQL serialization still stores path values as bytes/BLOBs.
- SQL deserialization expands stored relative paths into `Path` values.
- `PathQuery` compares `Path` values while generating SQL against the stored byte representation.
- Legacy database contents and migration code continue to round-trip correctly.
- `LibModel.path` and `Album.artpath` compatibility behavior is deliberately documented by tests.

## Suggested fix

Move encoding and decoding into `dbcore` path type/query helpers. Runtime model code should see `Path`; SQLite should see the same byte representation beets already relies on.

## Acceptance criteria

- Model path fields are `Path` at the Python boundary.
- Stored SQL values remain bytes/BLOBs.
- Tests cover relative path storage, database round trips, legacy rows, query matching, and undecodable path behavior.
- `poe test` and `poe lint` pass with coverage at or above 80%.

Start with the dbcore path type and query helpers, then trace the LibModel.path and Album.artpath model fields and their compatibility tests. Run the relevant tests through `poe test` and check `poe lint`; done means Path values reach Python models, SQLite retains byte storage, legacy and undecodable paths round-trip, and coverage remains at least 80%.

Written by the indexing model from the issue text.