pdb: read the artist/album name offset from the row, not a hardcode

[vynulldev]

What & why

Serving a rekordbox USB mis-displayed some artists as hundreds of bytes of concatenated names (the root cause the export-sanitize fixes in #49 masked). The pdb reader assumed each artist/album name sat at a fixed row offset (10/12 artists, 22/24 albums), but the real DeviceSQL format stores the name OFFSET in the row — a u8 for the near variant, a u16 for the far — and the string at that offset. A short ASCII name happens to sit at 10, so the hardcode worked for most rows; a longer or UTF-16 name (e.g. an artist with "ø") sits further along, so the hardcode landed on padding, read a length-kind byte of 0x00 (neither the ASCII nor UTF-16 flag set), and the decoder's fallback returned the whole rest of the string heap.

The reader now reads row[9] / row[10:12] for artists and row[21] / row[22:24] for albums, per the documented layout, and widens the id reads from u16 to the real u32.

Safe for working libraries: where the hardcode was right, the name already sat at that offset, so reading it back yields the identical result. Validated across five real pdbs (a problem stick plus four exports) — every previously-correct artist unchanged, only the over-read rows fixed, zero regressions. TestParseArtistRowReadsNameOffset pins it with short-ASCII and UTF-16 rows built to the real format.

Hardware testing

• Tested on: parser-level change; validated against five real export.pdb files (diff of old-hardcode vs new-read-offset artist maps: 0 regressions, over-reads fixed). Serving the affected stick now shows correct artist names in the library and deck browse. Covered further by the v0.5.0 served-USB checklist.

Checklist

• go build ./..., go vet ./..., and go test ./... pass
• gofmt -l . is clean
• New source files carry an SPDX header (GPL-3.0-or-later)
• Tested on real hardware (deck + firmware noted above), or this change doesn't affect deck behaviour
• I agree my contribution is licensed under the project's GPLv3