fix: apply address bar rule without page URL

[liby]

Fixes #99

Problem

With a Browser Rules address bar default input source configured, focusing an empty Chrome omnibox and typing while a Pinyin input source is active switches the input source only after the first keystroke. The switch lands mid-composition, which can leave an orphaned candidate window: the omnibox stops responding to Enter and Delete until the input source is toggled manually.

Root cause

An empty omnibox exposes no observable web-area URL, so AppKind.from classified the browser as a normal app and the address bar rule could not fire on focus. It only fired after the first key triggered another accessibility event.

Changes

• Make BrowserInfo.url optional and treat address bar focus alone as a browser context, so the address bar rule applies on focus, before typing starts (AppKind.makeBrowserInfo).
• Keep the context stable while the address bar stays focused: URL changes during editing reflect omnibox edits or suggestions rather than navigation, and no longer re-trigger input source switches (isSameAppOrWebsite).
• Website rules, tab switching, and navigation outside the address bar keep their existing URL-based behavior; browser states without a URL produce no website id, so they never pollute the per-site keyboard cache.
• Unwrap the now-optional URL in StatusItemController's browser rule menu.

Testing

• New unit tests: Tests/AppKindComparisonTests.swift (9 cases) covering browser context creation with and without a URL, entering/leaving the address bar, suggestion-driven URL changes, and navigation (run via Cmd+U).
• Manual scenario on a Debug build with Pinyin Simplified + Chrome: focusing an empty omnibox now switches to the address bar input source before the first keystroke and the candidate window no longer gets stuck; suggestion changes while typing do not re-trigger switches; website rules resume after leaving the omnibox.