fix: truncate long image filenames when saving to prevent ENAMETOOLONG

[ibrahim-iqbal]

Fixes #1315.

`URLUtil.guessFileName()` derives the save-target name from the URL when the response doesn't carry an unambiguous `Content-Disposition`. For image URLs with long titles / hashed paths, that name can exceed the 255-byte filename limit ext4/f2fs enforces on Android. `ContentResolver.openFileDescriptor` then blows up with:

```
java.io.FileNotFoundException: open failed: ENAMETOOLONG (File name too long)
at me.ash.reader.infrastructure.android.AndroidImageDownloader.downloadImage2.invokeSuspend(AndroidImageDownloader.kt:181)
```

The tap-to-save flow is a 100% crash on any image whose guessed name goes past the limit — reproducer in #1315.

Added a small `sanitizeFileName` helper that caps the name at 200 chars (headroom under the 255-byte limit for typical single-byte scripts) while preserving the file extension so the saved file still opens as an image. Applied at the single call site right after `URLUtil.guessFileName` so both the Android Q+ MediaStore path and the pre-Q direct-file path get the sanitized name.

Test plan

Would need a device to verify end-to-end, which I don't have set up for this repo. Logically covered:

• Short name: `image.jpg` (9 chars) → unchanged, early return.
• Long name with valid extension: 300-char base + `.jpg` → truncated to 196 chars + `.jpg` = 200 chars total, still valid image.
• Long name with no extension: 300 chars → truncated to 200 chars.
• Long name with pseudo-extension (`.thing-that-is-long`, 19 chars): treated as no extension, kept, truncated to 200 chars total.

Happy to add a unit test if you'd like — didn't see an existing test file for AndroidImageDownloader in the app module, so didn't want to seed a new one without your steer.