feat(forge): Gitea/Forgejo and Bitbucket support

[BryanFRD]

Problem

`src/forge/mod.rs:57` (`detect_forge_from_url`) only matches `github.com` and `gitlab.com` (plus `workspace.forge` explicit override). Self-hosted Gitea/Forgejo/Codeberg setups fall through silently — the user must add a hook to create releases manually via curl.

Closes most of the homelab / cooperative-hosting / non-Microsoft-or-Atlassian audience out of FerrFlow's release-creation UX.

Comparison

semantic-release plugins cover all four (semantic-release-gitea, semantic-release-bitbucket, etc.). changesets has community plugins.

Proposal

Add two new forges:

• Gitea (covers Gitea, Forgejo, Codeberg — API is nearly identical to GitHub v3, just `/api/v1` prefix and slightly different auth header). `src/forge/gitea.rs` modeled on `github.rs`, ~80% code reuse.
• Bitbucket (Cloud + Server) — different API surface, lower priority. File separately if Gitea ships first.

`ForgeKind` enum extension:
```rust
pub enum ForgeKind { Auto, Github, Gitlab, Gitea, /* future */ }
```

Detection: hostname allow-list (`gitea.io`, `codeberg.org`) + path-based fallback for self-hosted (try GitHub-shape first, then `/api/v1/version` Gitea probe, cache result).

Auth: `GITEA_TOKEN` / `FORGEJO_TOKEN` env vars + per-host token lookup.

Out of scope

• Pull request creation parity (PR mode currently GitHub/GitLab-only — Gitea has it but the API shape differs slightly).
• Bitbucket — separate issue once Gitea lands.

Test plan

• Unit tests for Gitea API client (mocked HTTP responses)
• Integration with a public Gitea instance (codeberg.org has a sandbox)
• Detection logic distinguishes Gitea from self-hosted GitHub

Related #332 (auto-detect self-hosted instances).