Better error handling

[yhurynovich]

Summary
Two bugs in the browser-based Z.ai auth flow, both causing the script to fail without a usable error message.

1. Script silently did nothing when invoked with a relative path
   The ESM "am I the entry point?" guard compared import.meta.url against a naive string concat of process.argv[1]:
   jsif (import.meta.url === file://${process.argv[1]}) { ... }
   import.meta.url is always an absolute, normalized file:// URL, but process.argv[1] is whatever was typed on the command line. Any relative invocation (node scripts/zai_browser_auth.js, as used by the npm run auth:browser script) — or any Windows path (backslashes, drive-letter encoding) — fails this comparison. main() was never called, and the process exited cleanly with zero output: no browser window, no error, nothing.
   Fixed by comparing against pathToFileURL(process.argv[1]).href instead of string concatenation. Also added an opt-in ZAI_AUTH_DEBUG_ENTRY=1 env var that prints the actual vs. expected URLs if this check ever fails again, to make this class of bug diagnosable next time.
2. Crash on the execution-context-destroyed race right after login
   The polling loop calls page.evaluate(...) (via readToken) every 2s to check localStorage for a token. The moment the user finishes logging in, z.ai navigates/redirects, which can destroy the page's JS execution context mid-evaluate. Puppeteer throws Execution context was destroyed, most likely because of a navigation, which was unhandled and killed the whole process right as auth was about to succeed.
   Fixed by catching this (and a few sibling Puppeteer errors — target/session closed, detached frame) around the readToken call and treating them as "retry next tick" rather than fatal, since the next iteration gets a fresh valid context.