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

**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`