[FEATURE] AUR maintenance, embedded wiki, multi package manager

[Firstp1ck]

Summary: Define phased support for AUR maintainer workflows, an in-app wiki reader, and long-term multi-backend package management (apt/dnf/Flatpak) behind a clear backend abstraction. Related planning: dev/IMPROVEMENTS/FEATURE_PRIORITY.md (AUR maintenance ~v1.4.0; multi-PM ~v2.0.0).

---

1) Maintain your AUR packages

Problem

Maintainers want to bump pkgver, update checksums, build, and push from a focused workflow.

Recommended implementation (phased)

1. Detect git AUR remotes for a package in clone path; show status vs upstream.
2. Recipes: updpkgsums integration (if present), makepkg --verifysource, optional namcap in pipeline (ties to PKGBUILD validation doc).
3. Publish: optional git push after confirmation; never hardcode credentials.

Acceptance criteria

• Each destructive step behind confirmation + dry-run preview of commands.
• Works when tools missing with explicit install hints.

---

2) Wiki inside the TUI

Problem

Users want Arch Wiki / project wiki content without leaving the terminal.

Recommended implementation

• Fetcher: HTTP client with caching; prefer simplified render (markdown → plain/ratatui text) rather than HTML engine in v1.
• Scope: Start with Arch Wiki API or curated article list + search; Pacsea wiki could be second source.
• UX: Buffer with TOC jumps via headings; open URL in browser keybind.

Risks

• Wiki HTML complexity; scope markdown/plain subset first.

Testing

• Fixture-based render tests; offline cache hits.

---

3) Multi package manager support (apt, dnf, Flatpak)

Problem

Same UX for non-Arch systems expands audience massively but contradicts current Arch-first design.

Recommended implementation (architectural)

1. Abstraction layer: PackageBackend trait: search, install, remove, update, list orphans — implemented by ArchBackend first.
2. Second backend: Pick one (e.g. Flatpak) as pilot; apt/dnf later — similar surface but different CLI.
3. Config: backend = arch | flatpak | …; hide incompatible features with clear UX.
4. Tests: mock CLI for each backend contract.

Non-goals initially

• Feature parity with every flag of apt/dnf; start with common flows only.

Acceptance criteria

• Default install is still Arch-oriented; enabling another backend is explicit.
• CI runs backend tests with mocks only.

Risks

• Massive maintenance surface; treat as major version theme with staged backends.

---

Tracking: dev/ROADMAP/OTHER_aur_wiki_and_multipm.md