Migration: the forge backend implies the forge¶

Spec 0195. Until this change a project's forge was three separate answers that could disagree: a --git-backend that only defaulted the host, five forge checkboxes in --features, and a release source decided by whether the host name contained gitlab. A default project enabled update and no forge, so it could not build its updater.

Flags¶

before	after
`--git-backend github`	`--forge-backend github` (also `gitlab`, `gitea`, `codeberg`, `bitbucket`). No alias.
`--features ...,github`	refused. The backend implies its forge; `--forge-credentials github` enables a further forge for its credential wizard and adapter only.
`--host` chose the backend by substring	`--host` is the host only, for a self-managed instance.
(none)	`--no-forge --module <path>` for a project that is not hosted on a forge.
(none)	`--release-channel forge\\|direct` when `update` is enabled, with the `--release-*` settings of the go/forge `direct` source.

Manifest¶

New fields, all derived and written back by the first regenerate on a manifest that predates them:

release_source.backend: from the single enabled forge feature, else the release type, else the host substring. Two enabled forges resolve through the release type and are refused when it names neither.
properties.module_path: <host>/<org>/<repo> for a hosted project.
properties.forge_credentials: forges enabled beyond the backend.
release_source.direct: the direct source's settings when the type is direct.

release_source.type accepts every backend and direct; Gitea, Codeberg and Bitbucket projects get no CI files, because no skeleton exists for them yet.

Generated tool¶

A default project now enables its backend's forge feature, links its adapter in cmd/<name>/forge.go, and can check for updates. doctor gains a "Release source" check that fails when the release source type has no registered provider, whatever the forge features say.