🗃️ Make archiving tables/applications a personal option

[AndyScherzinger]

• Resolves partially Make archiving tables/views a personal option #2125

🖼️ Screenshots

Archived categories	Archive app	Archive table	Unarchive app	Unarchive table

The original ticket #2125 defined tables and views, while this PR tacked tables and apps. Given a clear view on how archived views should get displayed this could be added as a follow-up PR to not make this PR grow in review-size and complexity.

---

Summary

• This change replaces the existing single-user global archived flag on tables with a two-layer per-user model: an owner-level flag on the entity and a new tables_archive_user table that stores individual user overrides, so archive state is resolved per-user at read time. When an owner archives a table or application, it is automatically treated as archived for every user with access, but any of those users may override this for themselves; an owner unarchiving resets the state for everyone by clearing all per-user overrides.
• The existing tables_tables.archived column is repurposed from a simple global toggle into the owner-level signal, and the database migration converts all currently-archived tables into owner-archived entries to preserve existing data without disruption.
• Application (context) archiving is introduced as a completely new capability end-to-end: covering database schema, entity, service, API endpoints, routes, and frontend navigation - while table archiving is substantially reworked from a simple owner toggle into the full per-user propagation system.
• A new ArchiveService centralizes all business logic for both resource types, four new API endpoints are split across ApiTablesController and ContextController following existing naming conventions, and the frontend gains archive/unarchive actions in both navigation item menus alongside a new collapsible "Archived applications" section mirroring the already-existing "Archived tables" section.

⚠️ Beware

The database migration only covers the owner and direct user shares, not groups, etc. since they can't be resolved directly via SQL (think teams/groups). So in these cases archived tables would resurface until manually archived by the respective user. Also there is no cleanup for teams/groups, if a user is taken out of a team, the archive meta-info would not get deleted. Only simple but confusing way around it would be to prevent archiving/unarchiving for tables/apps where a user is neither the owner nor a user-share receiver. Expensive alternative would be a housekeeping job checking all these archive bits periodically, but that also sounds expensive with little use. Else we would need to consume a team/group changes event and check if some cleanup is needed. WDYT?

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔙 Backport requests are created or not needed: /backport to stableX.X
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI

[jancborchardt]

Looks generally nice, 2 details

• I’d say to use outline icons instead of filled for both cases, archiving and unarchiving
• In the cases of "Archive app" and "Unarchive app", the sorting of actions in the menu is off. We always recommend the destructive action (Delete) to be the very last, and then the next most destructive like Archive could be directly above it.

[AndyScherzinger]

@samin-z regarding #2476 (comment)

Fixed in 6f4140f
fix(archiving): pass context type as typeParam in RequirePermission

Instead of extending the middleware's numeric whitelist as suggested, the two endpoints now pass typeParam: 'context' like every other context endpoint in the controller, so the existing string-based context detection in PermissionMiddleware applies.