settings: an unrelated history entry while Settings is open buries its entries #898

Split from #564: main already handles a slow traversal landing after the give-up, bounds the rewind retries, and gives the pages regression async waits and ko/ja/zh/key bar editor coverage (#630). The regression already compares each control with its nearest .settings-card (#562).

Remaining

• A markerless navigation while Settings is open buries the Settings entries. Examples are a typed #hash or another script's pushState without the marker.
• Repro (fake history stack): open Settings at depth 3, then run a markerless pushState and fire popstate. App's onSettingsHistory listener closes Settings and the module asks for no traversal. One Back then lands on the depth-3 entry again, which restores the page or editor that was supposedly closed.
• Root cause:
  • src/App.tsx:237-242 closes Settings on every non-own markerless landing.
  • src/lib/settingsHistory.ts:40 (settingsEntry) and :72 (reconcile takes the held depth from the marker) know an entry only by the marker.
  • As a result, a Back to the base entry and a new foreign entry look the same.
• Fix:
  • Track the Settings opening's base entry (an id written into the base state, or the history length at opening) and the module's own entries explicitly.
  • This tells a markerless popstate apart from stepping under the dialog.
  • Cleanup should then step back over the foreign entry or rebuild from the base.
  • Simply ignoring markerless landings breaks the dialog's normal Back, and stepping over all of them can step past a real Back.
• Add fragment and auth-navigation coverage.