[FEATURE] Upgrades, rebuilds, and conflicts

**Summary:** Improve upgrade reliability with `rebuild-detector` integration, configurable upgrade command templates, and phased dependency-conflict guidance/resolution focused on safety-first UX. Related planning: `dev/IMPROVEMENTS/FEATURE_PRIORITY.md` (conflicts ~v1.3.0).

---

## 1) rebuild-detector integration

### Problem

After soname or dependency bumps, AUR/local packages may need rebuilds; users want visibility before/after `pacman -Syu`.

### Recommended implementation

- **Detection:** If `rebuild-detector` is installed, run its documented non-interactive mode (or parse its output) from a background job; cache results with package graph version.
- **UI:** Badge or list “needs rebuild” with reason string from tool output; action to run suggested rebuild command via integrated executor (with dry-run).

### Acceptance criteria

- Clear behavior when tool missing: info message, no error storm.
- Timeout and size limits on output parsing.

---

## 2) Custom upgrade commands

### Problem

Power users wrap `paru`/`yay`/pacman with custom flags or scripts.

### Recommended implementation

- **Config:** `upgrade.command` template or argv list with placeholders: `{sudo}`, `{aur_helper}`, etc.; or predefined modes `pacman_only`, `aur_helper`, `custom`.
- **Safety:** Parse into argv array; no shell unless explicitly opted in with big warning.
- **Dry-run:** Print resolved argv.

### Acceptance criteria

- Default behavior unchanged when config absent.
- Invalid config: fail at startup with path to setting key.

---

## 3) Dependency conflict resolution

### Problem

`pacman` / AUR helpers sometimes stop with conflicts; users want guided resolution.

### Recommended implementation (incremental)

1. **Phase A — Explain:** Parse pacman error output into structured “conflict set” model; show human-readable graph (which pkg wants which version).
2. **Phase B — Suggest:** Offer curated safe actions when unambiguous (e.g. remove conflicting AUR package); never auto-remove without confirmation.
3. **Phase C — Simulate:** `pacman -Sp` / dry transaction if available; surface what-if list.

### Risks

- Incorrect automated resolution can break systems; bias toward education + explicit user confirmation.

### Testing

- Golden-file tests on sample pacman stderr transcripts.

---

Tracking: `dev/ROADMAP/OTHER_upgrade_workflows.md`