Baixar ghtkn 0.3.5 per a Windows

⚠️ Redesign Agent Skills
#556 consolidate the agent skills into a single ghtkn skill
If you installed the old skills ghtkn-*, please uninstall them and re-install the new skill ghtkn instead.
e.g.
rm -Rf ~/.claude/skills/ghtkn-*
gh skill install suzuki-shunsuke/ghtkn ghtkn

Features
#555 Add ghtkn exec to run a command with access tokens in environment variables
#558 Support .apps[].git_owners to select one app for several repository owners

Bug fixes that come with ghtkn-go-sdk v0.5.1
https://github.com/suzuki-shunsuke/ghtkn-go-sdk/releases/tag/v0.5.1
Both fixes are about the command the device flow runs to open the browser, and both share the same exposure. macOS is unaffected in practice, because open neither writes to stdout nor reads stdin, and Windows never reaches this path. Linux is the real one: the browser candidates include Debian's www-browser alternative, which resolves to a text browser such as w3m, lynx or elinks on some hosts. The SDK only checks whether one of the candidate names is on PATH, so on a headless host with w3m installed it considers a browser available and runs it.

The browser command's stdout no longer lands on ghtkn's stdout
ghtkn-go-sdk#404
The browser command inherited ghtkn's stdout, which is not spare: ghtkn get writes the access token to it, and ghtkn git-credential speaks git's credential protocol on it. A text browser renders the whole page to stdout, so GH_TOKEN=$(ghtkn get) would capture that output along with the token, and git would fail to parse the credential. The failure looks like a bad token rather than like browser output, which is the kind of thing nobody would think to look for. The command's stdout now goes to stderr, so the output still reaches the terminal without touching the stream callers parse.

The browser command no longer reads ghtkn's stdin
ghtkn-go-sdk#405
The same command read ghtkn's stdin, which carries git's credential request in ghtkn git-credential and the user's Enter key in the device flow prompt. A byte the browser command consumes is a byte ghtkn never sees, and the failure looks like a truncated credential request. The command's stdin is now the null device.
One behavior change is worth calling out: a text browser now sees EOF and exits instead of taking over the terminal. The verification URL is already printed to stderr for the user to open, whereas a text browser being driven by a credential request is not a state anyone can act on.