[No QA] Lighter design treatment for tables, cards, and theme tokens

[shawnborton]

Details

Applies a lighter design treatment across tables, cards, and theme tokens. Drops shadow/border decoration on card-like surfaces (search table wrapper, bordered content cards, widget containers, workspace more-features tiles, card section containers), reworks TableHeader/TableRow to rely on cardBG and only apply horizontal margin in narrow layout, and adjusts WorkspaceCompanyCardsTable wide layout to wrap header + body in a shared searchTableWrapper.

Theme token updates:

• Bumps cardBG from productLight100/productDark100 to productLight200/productDark200.
• Shifts border to productLight400/productDark400 and removes borderLight.
• Introduces a new activeNavItem token (productLight300/productDark300) and routes sidebar active + menu-item active states through it; activeComponentBG and hoverComponentBG now point to the next step darker.
• Bumps buttonDefaultBG/buttonHoveredBG/buttonPressedBG one step darker.
• TripRoomPreview reservation list drops its border/shadow.

Fixed Issues

$
PROPOSAL:

Tests

1. Open the app on web in both light and dark themes.
2. Navigate to Workspaces > Company Cards and verify the table renders with the new lighter treatment (no border/shadow on the wrapper, header + body share a single wrapper in wide layout, narrow layout retains mh5).
3. Visit Settings > Workspaces and confirm the More Features tiles no longer show a border/shadow.
4. Open a trip room and verify the reservation list no longer has a border/shadow.
5. Hover/active states on sidebar items and nav tab bar items use the new activeNavItem/sidebarHover tokens.
6. Buttons in default/hover/pressed states pick up the new one-step-darker backgrounds.

• Verify that no errors appear in the JS console

Offline tests

N/A — styling only.

QA Steps

[No QA]

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the `### Fixed Issues` section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the `Tests` section
  • I added steps for the expected offline behavior in the `Offline steps` section
  • I added steps for Staging and/or Production testing in the `QA steps` section
  • I added steps to cover failure scenarios
  • I turned off my network connection and tested it while offline
  • I tested this PR with a High Traffic account
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors
• I followed proper code patterns
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes
• I verified all code is DRY
• I verified any variables that can be defined as constants are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function
• If the PR modifies the UI:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added `Design` label and/or tagged `@Expensify/design` so the design team can review the changes.
• If the `main` branch was merged into this PR after a review, I tested again

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[dannymcclain]

@shawnborton this seems like a fun one - can we generate an ad hoc for it? Or will you when/if it's ready?

[shawnborton]

This was an older POC I had made - I just wanted to push it because I want Claude to be able to reference it in another POC I am making... stay tuned!

[dannymcclain]