Navigation slots

Purpose: Keep the phone tab bar short while giving each reader one-tap access to the destinations they use most, without the server knowing anything about them. Scenario: On a phone the bar shows Board, Calendar (while event support is on), New post and More, plus one or two personal slots. A reader opens Recent from More three times; on the next page Recent is a tab, before first paint, and stays there through twenty visits to other destinations. Users overtakes it only after leading by three uses across two different days. On a page listed in More, the More tab takes that page's name and the selected look, unless the page holds a slot. Clearing browser storage restores the default bar; every destination stays reachable from More. On desktop every main destination is in the top bar and You holds Profile, Account, Invite and the theme controls, so slots do not apply. Sources: slot count and sections (source unavailable) (navSlotCount(), navigationItems()), head script (source unavailable) (reads forum_nav_slots, sets data-nav-slots before paint), rules and storage (source unavailable) (FILL, LEAD, decide()), bar and More markup (source unavailable), per-section slot rules (source unavailable) (critical section, html[data-nav-slots~=…]), browser check (source unavailable), pre-paint check (source unavailable). Boundary: Server HTML is the same for every viewer and every width; CSS and the browser decide. State lives in one local-storage key as JSON (internal state, so not the Key: value format), per browser, never synced. Messages can hold a slot only in a browser remembered as approved; the member-only rule hides it regardless of stored state. A slotted tab keeps its place in DOM order (before Calendar) and is moved after the fixed tabs visually, so keyboard order differs from visual order by one tab. Adding a slottable destination means a new html[data-nav-slots~="…"] rule in site.css; the head script only accepts sections the server lists.