Bins: Add hierarchical parent-child organization #336

What problem would this solve?

Bins are currently presented as one flat list. As a library grows, related manual and Smart Bins become difficult to scan and every Bin menu, picker, and drop-down becomes increasingly unwieldy. Prefixing names to simulate groups is noisy and does not produce consistent grouping across the app.

What should become possible?

Allow each Bin to select an optional parent Bin. A Bin with no parent remains at the root.

• Add a Parent Bin setting to Bin creation and editing, with a clear No parent option. Exclude the Bin itself and its descendants from the available choices.
• Support parentage for both manual and Smart Bins. Parentage organizes Bins only: it must not imply clip membership, inherit Smart Bin rules, run parent Transforms, or inherit protection, concealment, hotkeys, or other Bin behavior.
• Render Bins as a consistently ordered hierarchy in the main navigation and everywhere Bins are listed or selected, including clip assignment controls, context menus, drop-downs, deletion/reassignment flows, hotkey and Transform controls, and other pickers. Group children beneath their parent and indent them with logical inline spacing so RTL layouts mirror correctly.
• Preserve enough context in compact menus where indentation alone is ambiguous, such as an accessible hierarchical label or path.
• Define deterministic sibling ordering and preserve the current root order when existing libraries migrate. Reordering a Bin within its parent must not disturb unrelated branches.
• Reject self-parenting, cycles, missing parents, and excessive depth through the shared Rust domain contract so the GUI, CLI, imports, and backups cannot create invalid trees.
• When a parent Bin is deleted, promote its children to the deleted Bin's parent while preserving their relative order. The existing clip disposition choice remains independent of this structural change.
• Include the parent relationship in Full Backup and Restore and History and Organization transfer. Validate the complete hierarchy before applying an import or restore, and fail transactionally on invalid data.
• Extend CLI parity: pasted bin create and pasted bin update should accept a parent Bin ID, update should support clearing the parent, duplicate should have a documented parent default, and --json results should expose a stable parent_id field. Human-readable bin list output should make the hierarchy clear without changing the meaning of existing Bin IDs.
• Update Bins documentation and add migration, validation, ordering, deletion, backup/transfer, GUI rendering, accessibility, RTL, and CLI structured-output tests.

Example workflow

1. Create a root Bin named Clients.
2. Create Acme and choose Clients as its parent.
3. Create manual and Smart Bins beneath Acme, such as Logins, Brand assets, and Recent links.
4. The sidebar shows the Acme Bins indented beneath Clients. Clip assignment menus, context menus, and pickers show the same grouping and order.
5. Move Acme to a different parent by editing its Parent Bin setting. The whole branch moves together, while clips and each Bin's rules and settings remain unchanged.
6. Scripts can create or move the same hierarchy through the CLI and reconstruct it from pasted bin list --json.

Alternatives considered

• Prefix Bin names (for example, Clients / Acme / Logins). This is manual, visually repetitive, and sorts inconsistently.
• Use tags for a second organizational axis. Tags describe clips rather than the relationship between Bins and do not group the navigation or selection surfaces.
• Group only the sidebar. That leaves the same flat, hard-to-scan list in assignment menus, context menus, settings, and automation.

Relevant surfaces

• Main app
• Quick HUD
• CLI or automation
• macOS
• Windows
• Linux or SteamOS
• Documentation or onboarding

Before submitting

• I searched existing issues and the Wiki.
• This request does not contain private clipboard data or credentials.