fix: support deterministic SSH login callbacks in init

[microHoffman]

Summary

• add --port <port> to githits init and forward it through the existing OAuth login flow
• use strict shared callback-port parsing for both init and login
• explain the loopback callback requirement and print the exact SSH local-forwarding command in --no-browser mode
• preserve existing local browser login and random-port behavior when no port is supplied
• distinguish interactive SSH login from API-token authentication for unattended environments
• add unit, command-registration, output, and source/built CLI smoke coverage

Why

--no-browser only suppresses browser launching. The OAuth callback server still listens on the loopback interface of the machine running GitHits. When GitHits runs on a remote VM but the sign-in URL is opened locally, the browser redirects to the local computer's loopback interface and cannot reach the remote listener without SSH forwarding.

login already allowed a fixed callback port, but init selected a random port. That prevented users from preparing a deterministic tunnel for the recommended onboarding command.

Impact

Remote users can now prepare a tunnel and run githits init --no-browser --port <port>. Invalid, partial, fractional, and out-of-range ports fail before authentication begins. Existing local login behavior is unchanged.

The repository documentation now contains canonical SSH/headless guidance and a handoff for the separately hosted documentation. A true tunnel-free device flow remains server-side follow-up work.

Validation

• bun test — 2,502 passed
• bun run typecheck
• bun run build
• bun run format:check
• bun run lint
• source CLI live and unauthenticated smoke tests
• source MCP live and unauthenticated smoke tests
• built CLI unauthenticated smoke under Node
• built MCP registration smoke under Node

Follow-up

• GitHits maintainers can apply the hosted-documentation handoff from docs/implementation/remote-authentication.md
• tunnel-free remote authentication would require RFC 8628 device-authorization support in the closed-source OAuth service

[skvark]

I'm sorry, but we don't have CLA in place and cannot yet accept external contributions. But I will add this to our backlog. Thank you!