fix(website): make the homepage card link hover class actually match

[IanoNjuguna]

Description

The three cards on the homepage are links, and the rule meant to suppress the hover underline never reached them.

HomepageFeatures/index.tsx passed the class as a plain string:

<Link className="featureCardLinks" to={link}>

while the rule lives in the CSS module as .featureCardLinks:hover. CSS modules hash local class names, so the emitted selector is .featureCardLinks_kdMv:hover — an element carrying the literal string featureCardLinks can never match it. The reset was therefore dead code and the cards underlined on hover, exactly as #323 describes.

The fix is one attribute: className={styles.featureCardLinks}.

Evidence

Measured on the deployed bundle with the hover state forced through CDP, rather than read off the stylesheet:

as shipped, :hover forced                  -> text-decoration: underline
same node with the module class added      -> text-decoration: none
resting state                              -> text-decoration: none

That third line is the point: the rule works, it was simply unreachable. It is present in the built CSS as .featureCardLinks_kdMv:hover { -webkit-text-decoration:none; text-decoration:none } — cssnano merges it into a larger hover group, so the declaration is live and correct.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Testing

• I have tested these changes locally

• I have checked for broken links — n/a, no content or link changes

• Code examples have been tested — n/a

• tsc --noEmit passes.

• Production build passes locally, and the PR build runs the same command in CI.

• Sibling sweep: I compared every plain-string className="…" in website/src against the local names declared in every *.module.css. This was the only collision in the codebase, so there is nothing else to fix in the same pass.

• After the change the built homepage carries the hashed class on all three card links (verified in the built output, see the comment below).

Notes for review

• The card lift and border hover styles are untouched; only the underline reset starts working.
• Related: The component & design-token baseline for human and agentic developers (spacing, typography, theme, etc) #300. This is a concrete example of the class-name-with-no-token problem that issue is about — a lint/AST check for "string class name where a module class or token is expected" would have caught it at build time.

Fixes #323

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my changes
• I have made corresponding changes to the documentation — n/a
• My changes generate no new warnings

[IanoNjuguna]

Verified on a local production build of this branch (head 7569402), hover states forced through CDP rather than eyeballed:

built homepage, three card links -> class="featureCardLinks_kdMv"   (the hashed class the rule expects)
emitted CSS                      -> .featureCardLinks_kdMv:hover { -webkit-text-decoration:none; text-decoration:none }

link, resting                    -> text-decoration: none
link, :hover forced              -> text-decoration: none           (was: underline on the deployed bundle)

inner card, resting              -> transform: none, box-shadow rgba(37,85,254,0.05), border rgba(37,85,254,0.1)
inner card, :hover forced        -> transform: matrix(1,0,0,1,0,-4) i.e. translateY(-4px),
                                    box-shadow rgba(37,85,254,0.15), border rgb(35,83,255)

So the underline is gone and the card lift, border and shadow hover styles are untouched — which is the behaviour #323 asked for.

Sweep for the same shape (a plain-string className="…" colliding with a CSS-module local name), across website/src: this was the only instance, so no sibling call sites needed the same fix.