Provide a signed Fedora repository for one-command native installation

[dskvr]

Follow-up to #34. Fedora users currently download an RPM plus checksum/signature material before invoking DNF. Provide a maintained signed Fedora repository so, after a documented one-time bootstrap, installation is sudo dnf install loopwire and upgrades use normal DNF commands.

Initial scope: Fedora 44, x86_64. Keep other Fedora releases/architectures outside this issue until separately tested, and retain the signed automatic installer as a fallback. The publication provider is still a decision: COPR or a project-owned DNF repository.

Development decision, implementation, and evidence: project-owned repository in #46. Production activation remains tracked by the Human operational tasks below.

Development tasks

• Evaluate and document the publishing approach. Compare COPR with a project-owned repository for release control, signed RPMs and repository metadata, Fedora 44 support, retention, and exact-artifact verification. Recommend one approach and record its configuration/credential requirements. Verify the provider can meet the signing and promotion requirements before committing to it.
• Implement the chosen package path. For project-owned hosting, reuse packaging/rpm/fedora-44.spec.in and scripts/build-rpm-package.sh. If COPR builds packages, add the necessary source-package/build configuration tied to the release tag/commit and capture provider build IDs. Validate the actual provider output; do not reuse VM proof from a different GitHub-built RPM.
• Implement and verify signing. Ensure distributed RPMs have valid OpenPGP signatures and the repository supplies signed metadata. Verify the provider-managed key or implement signing for project-owned hosting. Finalize signing before recording final package checksums and native-package evidence.
• Implement publication, retention, and rollback. Generate/obtain complete repository metadata, stage the candidate package set, and promote it only after validation. Preserve an installable previous version, make retries idempotent, prevent metadata/package mismatches, and document rollback. For COPR, prove the chosen staging/release mechanism prevents untested output becoming the stable channel.
• Integrate protected release automation. Invoke the selected publisher after existing release gates, wait for provider build/signing/publication completion where applicable, and propagate failures. Add affected-input CI coverage and a fixture/dry-run mode without production credentials.
• Provide Fedora repository bootstrap. Document the tested COPR enablement command or ship a .repo definition for project-owned hosting, including the HTTPS endpoint and verifiable key fingerprint. Keep package and repository-metadata signature checks enabled; document repeat-safe setup, repository removal, and key rotation.
• Add signing and publication regression tests. Reject unsigned/tampered RPMs, modified/unsigned metadata, and wrong keys. Check version/architecture selection, repeated publication, incomplete builds/uploads, and recovery to the previous package set.
• Add clean Fedora 44 lifecycle tests. Install through the configured repository, then test reinstall, upgrade from an older published version, removal, and rollback. Capture package origin, signature verification, installed version, GUI/provider smoke results, and commands/logs using the final published RPMs.
• Update user and maintainer documentation after public verification. Update the Fedora homepage tab, install guide, support matrix, release guide, and unreleased notes. Separate bootstrap from sudo dnf install loopwire, document DNF upgrades and release-support policy, and remove the manual local-RPM signature exception from the new repository path. Retain the automatic-installer fallback and identify this as a third-party repository.

Human operational tasks

These require maintainer access to provider accounts, signing material, or GitHub settings. Fixture tests and package tooling can proceed before production access exists.

• Select the provider and responsible maintainer. Use the development recommendation to choose COPR or project-owned hosting; record the owner/project identifier or public base URL and initial Fedora 44 scope.
• Provision the selected service. For COPR, create/access the Fedora account and project, configure the Fedora 44 x86_64 build target and maintainer permissions. For project-owned hosting, provision storage, HTTPS/DNS as needed, staging/production locations, and scoped upload access. Mark this item with the chosen path when complete.
• Establish the signing identity and recovery ownership. For provider-managed signing, record and verify the project's public key/fingerprint and key-change procedure. For self-managed signing, create/select the OpenPGP key and arrange backup/rotation. Do not export a provider's private signing key into GitHub.
• Configure the protected GitHub environment. Add the provider API/upload credentials and public project/URL settings required by the implementation; add private signing material only for self-managed signing. Verify release permissions and credential access without putting values in issue comments.
• Complete the first production publication. Run the release-to-repository workflow, verify the final public repository from a clean Fedora 44 guest, and attach the provider/workflow build IDs, repository URL, signing fingerprint, installed version, and lifecycle logs to this issue or its PR.

Done when: the chosen public channel serves authenticated Fedora 44 packages and metadata; publication is repeatable and recoverable; final-artifact lifecycle/tamper tests pass; and homepage/docs show the verified bootstrap plus normal DNF installation. A command alias around the existing multi-download process is insufficient.

Provider references: COPR setup and build inputs and COPR build/signing architecture. Signed-metadata support and stable-channel promotion must be validated during provider selection. Related channels: #35 and #37; share RPM signing/repository tooling with #37 where appropriate, while keeping Fedora-specific recipes and proof separate.