fix(naming): don't lose a series position that isn't a plain number

[m4bard]

Summary

Fixes #764.

Audnexus reports a series position as a string, and it is not always a number. Squeezing it through a decimal lost it in two ways, and the loss reached the filename.

Real positions from the catalogue (public domain, verifiable against api.audnex.us):

Book	ASIN	position
The Father Brown Collection: Books 1-4	B0F84DFZ66	"1-4" — one ASIN, four books
The Thirty-Nine Steps	B002V1PLZK	"1-2" — the product also ships Greenmantle
She and Allan	B00CQ5WAXW	"0" — a prequel slot
a novella between two books	—	"1.5"

The parse used the server's culture. decimal.TryParse was called with no CultureInfo, while FileNamingService formatted the result back with InvariantCulture. The source always uses . as the decimal separator, so where . is the group separator the number changed:

en-US      "1.5" -> 1.5     "0.5" -> 0.5
de-DE      "1.5" -> 15      "0.5" -> 5
fr-FR      "1.5" -> null    "0.5" -> null
invariant  "1.5" -> 1.5     "0.5" -> 0.5

A position that didn't parse was silently discarded. It became null — indistinguishable from a book with no position — so naming fell through to the track number and wrote that into the filename instead. No error, nothing in the log.

Changes

Added

• AudioMetadata.SeriesPositionRaw — the series position exactly as the metadata source gave it. SeriesPosition (decimal?) is kept for callers that sort or compare, but it cannot hold "1-4" and no longer pretends to.
• SeriesPositionReproTests — 10 cases covering culture handling and non-numeric positions.

Changed

• Audiobook.CreateBasicAudioMetadata and DownloadImportService now parse the position with InvariantCulture.
• Both naming sites (FileNamingService.Helpers, DownloadImportService) prefer SeriesPositionRaw, then the invariant-formatted decimal, then the track number. DownloadImportService previously formatted with a bare .ToString(), which would write 1,5 — with a comma — into a filename.

Fixed

• A non-numeric but real series position is no longer replaced by the track number when a file is renamed.
• A decimal position no longer changes value depending on the server's locale.

Testing

SeriesPositionReproTests (10 new cases):

• a decimal position survives under en-US, de-DE and fr-FR
• a decimal position is written invariantly, so no locale decimal-comma reaches a filename
• "1-4" and "1-2" are preserved and reach the filename rather than being replaced by the track number
• a book with no position still falls back to the track number, as before
• "0" survives

dotnet test: 1199 passing, 0 failing (1189 existing + 10 new). No existing test was changed.

Notes

The fall back to the track number is deliberate and is preserved — a book with genuinely no series position still gets it. The bug was that a real position was being treated as an absent one.

Apologies for opening this before the issue; #764 has the write-up. I've read CONTRIBUTING.md properly now.

Out of scope but worth flagging while it's in view: a book can hold two series memberships at once. Audnexus gives She and Allan (B00CQ5WAXW) seriesPrimary = Ayesha #0 and seriesSecondary = Allan Quatermain #7. MetadataConverters reads both, but AudiobookSeriesMembership is never constructed outside tests, so neither is persisted. Happy to open that separately if useful.