Read refusals skip the visibility flush after the disk recovers #431

A recovered runtime read outage can still prevent the final save when the app goes into the background. This is pre-existing behavior, found during independent review of the final background retry follow-up to #426. It is deferred issue work, not part of that PR.

Source-confirmed path

1. Load a valid data.json, then make a pre-write read fail while playback progress or another edit is pending. The runtime refusal becomes unreadable-data-file.
2. Restore reads before the next 10-second retry.
3. Put Obsidian in the background. The visibilitychange handler in src/main.ts calls player.save() and then flushSaves().
4. flushSaves() returns immediately whenever any write refusal exists. It does not let the writer attempt the good read that could lift this refusal. Pending work therefore waits for the normal timer even though this path exists to save before a mobile OS suspends or kills the app.

If the app is killed before that timer runs, the pending changes can be lost. The new re-arm behavior for later background edits does not fix this flush gate.

Evidence and limits

Source inspection on base 95790ba8a176b3fdfeae07ee8b250e160aa67da2 and follow-up head 34c910f7c4acffe982b6e8ffc1f4a0f4d2207d7a: src/main.ts visibility handler at lines 162-169, flushSaves at lines 565-569, and DataFileWriter.flush. The early return is unchanged. An independent Claude review traced the call chain. Android suspension or process termination was not reproduced live for this finding; the risk follows from the skipped flush and the existing lifecycle contract.

Expected behavior

A visibility flush should be able to retry a transient read refusal when the writer has a loaded document and pending work. Keep startup refusal with no loaded base protected, retain closing/schema refusals, and avoid duplicate Notices. Do not broadly remove the refusal gate or write defaults over an unread startup file.

Refs #426. Related strict-save recovery is tracked separately in #430.