fix: NoSuchFileException in card template fragment

[criticalAY]

Note

Assisted-by: Claude Opus 4.6 - Reproduction of the issue
Turn on Don't keep activitiy -> open template editor -> press home -> clear AnkiDroid cache -> open AnkiDroid -> crash -> report
(I tried in Tablet)

Purpose / Description

The previewer was crashing after process death. Android restores the activity, the ViewModel tries to rebuild by reading a temp file we'd stashed earlier, and the file is gone so the constructor throws and the app dies. so bug: SavedStateHandle promised durability, the file didn't deliver it.

Fixes

• Fixes java.nio.file.NoSuchFileException: /data/user/0/com.ichi2.anki/cache/notetype957925729682963336.tmp #20781

Approach

• I switched out of the cache directory i.e. Temp notetype files used to live in cacheDir, which Android is allowed to wipe whenever it wants - low storage, OEM cleaners, user tapping "Clear cache." [this is what i did] Now they live in noBackupFilesDir.
• Since the OS no longer evicts the files for us, the ViewModel now deletes its temp file in onCleared()
• the fragment detects this at the start of onViewCreated and just finishes the activity instead of letting the ViewModel blow up

How Has This Been Tested?

Emulator API 31 tablet

Learning (optional, can help others)

I am open to any other suggestion but this is what i can think of even note editor is finished when we do that same or dont keep activity is turned on

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[david-allison]

I haven't explicitly fixed these as I suspected there was more going on here.

It seems unusual that so many issues are coming from the OS clearing the cache, and I was concerned there was another bug at play.

If we are going to fix this:

1. Audit all screens which use IdsFile, add a tracking issue, and sub-issues to ensure that the IdsFile is deleted in all cases
   • I suspect that undeleted IdsFile instances are a major cause of this issue: larger caches -> more likely the cache is cleared.
2. IdsFile.getIds() should return a nullable list
3. Each screen should properly handle IdsFile.getIds() failing, likely by an early finish(), I'm not sure if the current handling of this issue is intuitive to developers, vs calling .finish() in the right place and skipping the ViewModel init