Status bar keeps showing the tapped wikilink target on touch screens

[adibhanna]

Seen on ZenNotes for Android 1.1.24 (core 2.53.0), Android 15 emulator. Cosmetic, not a blocker; filing so it is not lost.

What happens. In Reading mode, tap a wikilink such as [[Alpha plan#Milestones]]. The target note opens correctly at the heading, but the left slot of the status bar (the footer) now reads Alpha plan#Milestones and keeps reading it. It only clears when you tap somewhere in the note body that is not a link. On a desktop with a mouse the same text appears while the pointer is over the link and disappears when the pointer leaves, which is the intended browser-style behaviour.

Steps.

1. On a touch device, open a note in Reading mode that contains a wikilink to another note.
2. Tap the link.
3. Look at the footer of the note that opened: the link target is shown and stays there.

Why. A tap on a touch screen makes the browser synthesize mouseover, mousemove and click, but never mouseleave. The mousemove handler in packages/app-core/src/components/Preview.tsx (the "Status-bar link preview" block) calls setHoveredLink(target) from packages/app-core/src/lib/hovered-link.ts, and StatusBar.tsx renders useHoveredLinkStore((s) => s.href) in its left span. The only things that reset it are the root's mouseleave (never fires on touch), a later synthetic mousemove on a non-link element (a tap elsewhere), or the Preview root unmounting. The click that opens the target note does none of these, so the value survives the navigation. The same store is fed from the CodeMirror mousemove handler in EditorPane.tsx, so Edit mode can show the same leftover after a tap on a link there.

Related. This is the same class of leftover as the wikilink hover preview card on touch, which the Android shell hides with a @media (pointer: coarse) rule on .note-hover-preview (zennotesandroid 1.1.24, issue ZenNotes/zennotesandroid#74). A shell-side CSS rule cannot hide only the footer's link slot without also hiding the rest of the status bar, and the text is still wrong state, so this one belongs in core.

Possible fixes, in order of how little they change:

• Clear the hovered link when a link is followed: call setHoveredLink(null) in the Preview onClick path that opens a wikilink or note link, and in the editor's link-open path. Cheap, fixes the reported case, and on desktop the pointer usually leaves the link anyway once the target opens.
• Clear it on navigation: reset the store when the active note path changes (a small effect in StatusBar.tsx or wherever the active tab is tracked), so no stale target can outlive the note it belonged to.
• Ignore synthetic mouse events on coarse pointers: skip setHoveredLink when window.matchMedia('(pointer: coarse)').matches (the check PromptModal.tsx already uses), so touch devices never populate the slot at all. Also removes the brief flash of the target during the tap.

Doing the first two together seems right: no stale target after following a link or switching notes, and hover keeps working on desktop.