Fix document name extraction from document properties

[thomasbuilds]

This PR fixes getCurrentDocumentName() in PdfViewer.java, which produced wrong or empty document names (used for the toolbar title and the Save-As default filename).

What was wrong

• It parsed the formatted, localized strings shown in the Document Properties dialog ("File name:\n…", "Title:\n…"). The labels come from R.string.file_name / R.string.title in DocumentPropertiesLoader, so any future translation would silently break it.
• On top of that, the original prefixes were also wrong: "File name:" was missing the trailing newline so replace() left a leading \n in the result, and "Title:-" never matched anything, so the title fallback was dead code.
• The filename selection used a brittle length > 2 check that could reject valid short filenames.

What this changes

• Resolves the document name directly from the raw Map<DocumentProperty, String> produced by DocumentPropertiesLoader, using the stable enum keys DocumentProperty.FileName (falling back to DocumentProperty.Title when its value isn't DEFAULT_VALUE). No string parsing of localized output.
• DocumentPropertiesLoader now returns a DocumentPropertiesResult carrying both the formatted List<CharSequence> used by the existing dialog and the pre-resolved documentName. The dialog UI is unchanged.
• PdfViewer caches the resolved name in a new mDocumentName field; getCurrentDocumentName() becomes a trivial accessor. The field is reset alongside mDocumentProperties on document change and loader reset.

Net effect: name resolution is fully decoupled from UI strings, so future translations of the property labels won't break the toolbar/Save-As behavior.

[muhomorr]

getCurrentDocumentName() has hidden dependency on UI string formatting in DocumentPropertiesLoader. This code will break after addition of UI string translations. Deeper changes are needed to address this issue fully.

[thomasbuilds]

Yeah you're right the prefixes "File name:\n" / "Title:\n" are built from R.string.file_name / R.string.title in DocumentPropertiesLoader.kt, so once those strings get translated, the parser silently returns "" and both the Save-As default name and the toolbar title break. This PR only fixes the :- typo, the missing \n in the File name: prefix, the leading-newline bug, and the brittle length > 2 check, the coupling to localized strings is still there.

To fix it properly I'm thinking:

1. Add a small DocumentPropertiesResult data class carrying both the formatted List<CharSequence> (for the existing dialog) and a pre-resolved documentName: String.
2. Have DocumentPropertiesLoader resolve the name directly from the raw Map<DocumentProperty, String> using the stable enum keys; DocumentProperty.FileName first (always a real OS filename, never "-"), falling back to DocumentProperty.Title when its value isn't DEFAULT_VALUE. No string parsing of localized output.
3. Change DocumentPropertiesAsyncTaskLoader to return DocumentPropertiesResult.
4. In PdfViewer, cache the resolved name alongside mDocumentProperties and reset it on document change / loader reset. getCurrentDocumentName() becomes a trivial accessor.

That way name resolution is entirely decoupled from UI strings, so future translations can't break it.
No change to the Document Properties dialog.

Happy to update the PR with this approach if that works for you.

[muhomorr]

Yes, the approach that you've described should be fine.

[ggtlvkma356]

I also noticed the Title:- match is essentially dead code, nice you have a fix for it.