Add Wired Business footer badge

[andrewzolotukhin]

Summary

Add a theme-aware Wired Business badge to the public landing-page footer using the provider's hosted SVGs and the existing footer badge conventions.

Original request

Add a new Wired Business footer badge with light and dark variants, and do not add a blog post.

What changed

• Added a Wired Business badge linking to https://wired.business in a new tab with noopener noreferrer.
• Used badge0-white.svg in light mode and badge0-dark.svg in dark mode at the supplied 200 × 54 dimensions.
• Added focused component coverage for the link, accessibility label, image sources, dimensions, and theme visibility classes.

Reasoning

This follows the existing themed hosted-badge pattern used by the landing-page footer. Keeping the provider-hosted SVGs in plain img elements preserves the supplied embed assets without expanding Next.js remote-image configuration for two small footer images.

Blog post

Skipped as explicitly requested. This is a small directory-badge addition and does not warrant a separate public feature announcement.

Validation

• npm run lint
• npm run typecheck
• npm test — 94 files, 516 tests passed
• Focused landing-page component test
• GitHub: Lint and test
• GitHub: Deploy PR environment
• GitHub: Playwright e2e
• Preview QA in light and dark modes at 1440 × 1000 and 390 × 844
• SigNoz verification for xpenser-web-pr-72

SigNoz showed successful RSC GET / traces with HTTP 200 responses and no error traces during the QA window. The service-scoped logs and HTTP metric queries returned no samples, so traces were the relevant telemetry signal for this static UI change.

Screenshots / Preview

Live preview: https://xpenser-pr-072.cleverbrush.com

Light mode	Dark mode

Manual preview QA confirmed:

• The expected 200 × 54 asset loads in each theme while the opposite variant remains hidden.
• The footer remains within the mobile viewport without horizontal overflow.
• The badge opens https://wired.business/ in a new tab.
• The badge link exposes the expected accessible name and noopener noreferrer relationship.
• No browser page errors or console errors appeared during the final pass.

Checklist

• I kept the change focused.
• I updated docs or tests where needed.
• I checked for secrets, local env files, and generated build output.
• API changes keep contracts, endpoint metadata, and handlers aligned (not applicable; no API changes).