Fork Forgejo and rebrand it as GitW3

[plansombl]

Description

We should create and maintain a fork of Forgejo — the community-driven, self-hostable Git forge — and rebrand it under the name GitW3. This would give MetaState full control over the platform's roadmap, theming, and integrations while building on top of a proven, open-source foundation.

Reference

• Forgejo upstream repository: https://codeberg.org/forgejo/forgejo
• Forgejo documentation: https://forgejo.org/docs/latest/

Acceptance Criteria

• A fork of the Forgejo repository is created under the MetaState-Prototype-Project organisation (or a dedicated org/repo as agreed)
• The project is renamed to GitW3 across the codebase (UI strings, config keys, branding assets, documentation)
• A custom logo and colour scheme reflecting the GitW3 / MetaState brand is applied
• A CI/CD pipeline is set up to build and publish GitW3 releases
• A process is documented for pulling upstream Forgejo changes into the fork to keep it up to date
• A basic README explains the relationship to Forgejo and the purpose of the fork

Desired Output (may vary)

A deployable, self-hosted Git forge running under the GitW3 brand, built on the Forgejo codebase, ready for further MetaState-specific customisation and integration.

🤖 Requested by @coodos via plansombl assistant

[Bekiboo]

Done, with two things called out below.

The fork is ensombl/gitw3, branched from Forgejo v16.0.2 (68794918).

Not done by me: the transfer to the MetaState org. @coodos said he'd take
care of it. Everything else below is in place and moves with the repo.

Deliberate deviation: config keys are not renamed. The Go module path
stays forgejo.org, the binary is still gitea in source (renamed at build
time via EXECUTABLE=gitw3), and the env prefix stays FORGEJO__/GITEA__.
Renaming them would mean touching thousands of lines, would blow up the patch
surface we're trying to keep at zero, and would make Forgejo's own
documentation unusable for whoever operates the instance. Rationale is in the
README.

---

• Fork created — ensombl/gitw3, pending transfer to the MetaState org.
• Renamed to GitW3 across the codebase — 1,942 strings across 103 locale
  files, plus templates, mail, SSH output, the install form, feeds, the API
  docs title and the Docker init scripts. Applied by
  branding/apply.sh, which rewrites ~100 upstream
  files in the working tree immediately before make build. Those rewrites
  are never committed, so our tracked diff against Forgejo stays empty and
  upstream security releases merge without conflict. Forgejo's own custom/
  mechanism can't do this: the Docker image points GITEA_CUSTOM at a
  volume, so the repo's custom/ is never read in a container, and the
  assets are embedded into the binary by the bindata tag anyway.
• Logo and colour scheme — original assets, following the MetaState
  platform logo convention. Note that Forgejo's own branding is not
  reusable: the logo is CC BY-SA 4.0 with an attribution exemption granted
  to the Forgejo project only, so ours had to be original work rather than a
  recolour. The palette is appended after upstream's :root block rather
  than patched over it — an upstream colour tweak can never conflict with
  ours — and covers all nine themes, since the auto and colourblind variants
  @import the two base ones. Default theme is now forgejo-light to match
  the other MetaState platforms.
• CI/CD — ci.yml builds with branding
  applied on every push and asserts the overlay reached the binary, so a
  build that silently ships Forgejo's name fails. Releases are cut by
  release.yml on gitw3-v* tags,
  publishing the binary, a checksum, GitHub release notes and
  ghcr.io/<owner>/gitw3. See the caveat below.
• Upstream sync process — procedure documented in
  docs/gitw3/upstream-sync.md; upstream refs
  are mirrored daily by
  upstream-sync.yml, which only ever
  writes to upstream-owned refs and never to main. This isn't optional
  maintenance — v16.0.2 and v15.0.6 were both security releases landing on
  the same day.
• README — explains the relationship to Forgejo, the branch model, the
  near-zero patch surface strategy, and the licensing constraint on branding
  assets.

---

One caveat on the release pipeline. The build half runs on every push and is
green. The publish half — GHCR push and GitHub release — has never executed,
because no gitw3-v* tag has been cut yet. The container image itself is known
good: it's what I've been running locally for the #1097 work. I'd suggest
cutting gitw3-v16.0.2 after the org transfer rather than before, so the
image doesn't get published under a namespace we're about to leave.

On scope. W3DS login is deliberately not implemented in this fork — that's
#1097, and it's provided by a separate OIDC bridge wired through Forgejo's
built-in OAuth2 authentication sources, so it needs no change to this codebase.
Keeping the fork's diff empty is what makes that possible.