Wire ArchiveTableModel into ArchiveTab (QTableView migration, Phase 4 pt 1)

[ebuzerdrmz44]

Description

Wires the ArchiveTableModel from #2517 into ArchiveTab, migrating the Archive tab from item-based QTableWidget to QTableView + QSortFilterProxyModel.Part of #2361 Phase 4.

⚠️ Stacked on #2517 : the diff currently includes the spike commits. Only the top 2 commits are new here; those review needed are:

• 3088310 Wire ArchiveTableModel into ArchiveTab
• 2d61227 Scope delete to repo, preserve scroll on refresh, ungate mount-open

Once #2517 lands I'll rebase onto master and the spike commits drop out.

Key changes:

• .ui: QTableWidget → QTableView; sort via QSortFilterProxyModel + setSortRole(SortRole) so non-string columns order by raw value, not lexically.
• Selection resolved through a single selected_archives() helper reading ArchiveRole : proxy-safe, so actions hit the right archive after sorting. All read sites (incl. archive_extract/archive_mount) route through it.
• In-place rename via view.edit() + model dataChanged; NoEditTriggers makes the explicit edit the only editor entry.
• Delete / failed rename refresh via populate_from_profile(preserve_view=True) (keeps scroll offset instead of jumping to top); delete query scoped to repo.

Related Issue

#2361 (Phase 4). Builds on #2517.

Motivation and Context

The item-based QTableWidget mixed data, formatting, and sort keys into widget items, which made sorting fragile (durations >24h sorted lexically, e.g. '1 day, …') and selection-after-sort error-prone. Moving to a QAbstractTableModel + sort proxy separates data from presentation, fixes the sort-key bugs, and makes selection robust under sorting via a custom data role.

How Has This Been Tested?

make test-unit (Borg 1.2.4) green, plus new tests for selection-after-sort and rename-failure revert. Manually checked sort → delete/rename hit the right archive.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have read the CONTRIBUTING guide.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.