Fix mobile panel touch targets + table cell margin alignment

[franksong2702]

This PR contains two small UI fixes:

1. Mobile Panel Navigation Touch Targets

• Expands touch targets for panel navigation icons on phone and tablet
• Before/after screenshots in docs/pr-media/2231/

2. Table Cell Paragraph Margin Alignment

• Fixes table cell content appearing misaligned and too spacious
• The Markdown renderer wraps table cell content in tags which inherited the global rule
• Added CSS rule to reset margin inside to 0
• This fixes tables appearing with weird vertical misalignment, especially noticeable on iPad

Testing:

• ✅ Tables now render correctly on both desktop and mobile
• ✅ No regression to regular paragraph spacing outside tables

[franksong2702]

Closing this draft because it mixed two unrelated scopes: the already-closed #2231 mobile panel navigation work and the separate Markdown table-cell paragraph margin fix. I'll reopen the table spacing fix from a clean branch with only the focused CSS/test changes.

[nesquena-hermes]

Deferred from stage-366 — architectural conflict with current mobile layout

Hey @franksong2702, when I tried to rebase this onto current master, the static/style.css mobile section has a fundamentally different layout strategy than your branch:

• Current master: uses .sidebar-nav (52px-wide vertical nav rail inside the sidebar, with .panel-view content offset by margin-left:52px).
• Your branch: uses .rail (52px-wide fixed-positioned rail outside the sidebar, with .main offset and the sidebar slid to left:-mobile-sidebar-width).

These can't both exist — they describe competing mobile shells. Same conflict shape applies to static/panels.js:248 (switchPanel now has new fromRailClick handling) and the mobile-layout tests.

To unblock: please reconcile your touch-target fixes (44×44px minimums, panel button sizing, table cell margin reset) onto the current .sidebar-nav layout rather than the .rail layout your branch introduces. The 44×44px touch-target invariants and the table-cell <p> margin reset are both still valuable; just apply them within the current sidebar-nav structure.

If you'd prefer to keep the .rail-based design as a separate proposal, that's a bigger architectural conversation — file as an issue first.