fix(track): caret follows right after app switches; Java carets via getCaretLocation (#365)

[Maxaubert]

Closes #365. Stacked on #364; GitHub retargets it to main when #364 merges.

1. App-switch gap.

• Apps fire focus events for a control that already has focus. Notepad and VS Code do it while typing, about 3 per app switch.
• Each one re-baselined the caret, so the first second of typing after a switch was not followed.
• A focus event with the same foreground window, focus window and element bounds now keeps the caret followed (src/focus_identity.h, unit-tested; focus repeat in trackLog).
• Zoom-in clears the key, so it still only baselines.

2. Java carets.

• The bridge's character bounds (getAccessibleTextRect) gave x=2 for every Swing caret, with y pinned to the top or bottom of the view.
• The caret now comes from getCaretLocation, scaled by the monitor DPI, because Java answers in its user space. The old call stays as a fallback.
• trackLog names the bridge call and the caret index, or why a read failed.

Verified on the signed UIAccess build (scripted runs; trackLog plus ground truth)

App	Before	After
Notepad	12 of 86 moves skipped after a switch, first follow about 1 s	0 of 36 skipped, first follow 0.3 s
Edge	3 of 120 skipped	0 of 36 skipped
Swing (JDK 21, 225%)	x=2 for every caret	42 of 57 reads within 6 px of the app's own caret record

For Swing, the remaining 15 reads are jumps across a 400-character line, where the app logged the caret position before it scrolled.

• build.bat test: 572/572 pass.

Not fixed here

• VS Code reports its caret at the start of the line (x=263) wherever it really is on that line. Wind sees line changes but not moves within a line. This predates this PR (Caret tracking in VS Code: caret reported as the whole line #341 territory).
• IntelliJ was not exercised: an "Open in Project" dialog blocked the scripted run.

Version 0.23.2.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KPUNAWcwghXdHCApcKKjSG