fix(team): featured card stacks below 640px (name one-charred at 390)

[lilyshen0722]

The 390px pass on the deployed tiers caught the #568 name-crush class reborn on the new featured card: 44px | 1fr | auto let the actions column squeeze the name to one character per line. Below 640px the card now stacks — actions drop to their own row. Invariant pins the media query (jsdom can't see layout). Screenshots of the defect and the fix land in the thread after deploy.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LJ1bDdDQwWekHDqweiBhRN

[lilyshen0722]

Gated at 9fa46243.

The CSS fix is correct, and I measured it rather than reading it. Both stylesheets served over http, Playwright at 390×844, same markup:

name on the featured card	main	this PR
Pod Architect	94px column, 2 lines	108px, 1 line
Commonly Summarizer Agent	94px, 3 lines	236px, 1 line
sprint-review-orchestrator	94px, 4 lines	212px, 1 line

The text column goes 110px → 256px, actions drop to their own row (actionsTop 130 > bodyBottom 110), and scrollWidth === clientWidth, so nothing overflows. This is a real fix for a real regression.

One correction to the comment, since it will outlive the PR and this file's #568 comments are already load-bearing: "crushes the name to one character per line" overstates it. Worst case I could produce is 4 lines at a 94px column, not per-character wrapping. The defect is real; the description isn't, and the next person to read that comment will calibrate against it.

---

1. This is two changes, and the title names the smaller one

fix(team): featured card stacks below 640px is 15 lines of CSS. The other 255 lines add a new SEO guide (self-hosted-ai-agent-platform) plus its page-count and button-count test updates. Unrelated to the mobile fix, and it's what makes the next finding bite.

2. Merge order with #1384 is load-bearing, and nothing enforces it

#1384 declares base main, but its tree already contains this PR's guide — its true delta against this branch is 295 lines, not the 556 it reports against main. So they are stacked in content without being stacked in metadata.

Measured with merge-tree at both current heads:

#1383 into main             CLEAN
#1384 into main, then #1383 CONFLICT  (3 files: guides.json,
                                       generate-seo-pages.test.mjs,
                                       V2Login.test.tsx)

Both PRs are individually green, and git merge-tree on the pair reports clean — because #1384 is a superset, not because they compose. Merge #1383 first. If #1384 goes first, this branch conflicts on all three shared files, and even after resolution its assert.equal(pages.length, 20) / toHaveLength(10) are wrong against a tree that already has 11 guides.

This is exactly the class #1353 documents. Worth re-basing #1384 onto this branch and declaring the stack, rather than relying on whoever merges to guess the order.