Add cookie-based authentication support

[ichoosetoaccept]

What does this PR solve?

Adds cookie-based authentication (auth_type: cookie) for on-premise Jira installations that use SSO, reverse proxy, or client certificate authentication.

This is useful when:

• Your Jira is behind an enterprise proxy that handles authentication (e.g., with YubiKey/smart card)
• You authenticate via SSO/certificates and get a session cookie
• Basic auth or PAT aren't available options

Changes:

• Add AuthTypeCookie constant to pkg/jira/types.go
• Add JSESSIONID cookie handling in pkg/jira/client.go
• Add cookie option to auth type selection in config generator
• Add configureCookie() function that validates and stores session cookie in keychain
• Add jira refresh command for easy session cookie renewal (no need to re-run full jira init)
• Update README with cookie auth documentation

How to test?

1. Run jira init and select "Local" installation
2. Select "cookie" as authentication type
3. Enter your Jira server URL
4. Sign in to Jira in browser (via SSO/certificate)
5. Copy JSESSIONID cookie from browser DevTools
6. Paste when prompted - cookie is validated and stored in keychain
7. Use CLI normally. When session expires, run jira refresh

Checklist

• [x] I have added/updated enough tests related to my changes.
• [x] I have also manually checked and verified that my changes fix the issue and doesn't break any other functionalities.
• [x] My changes are backwards compatible.

[ichoosetoaccept]

Note: I noticed #870 also adds cookie support. My PR was developed independently for a different use case, but there's overlap.

Key differences in this PR:

• Focused on on-premise installations with SSO/reverse proxy/client certificate auth (where the browser handles auth and you get a session cookie)
• Adds jira refresh command for easy cookie renewal without re-running full jira init
• Validates the cookie via /myself endpoint before storing
• Stores cookie securely in system keychain
• Includes README documentation

Happy to coordinate with @johanneslarsson or defer to maintainer preference on how to proceed. The implementations could potentially be merged or one chosen over the other.