fix: clear the two warnings CI actually owns

[lorem-dev]

Removes the two warnings in CI that come from this repository's own code. Enumerated from the real logs of a develop run rather than from memory, then traced to a cause each.

What CI was warning about

Six distinct classes. Two are ours.

Warning	Source	Action
react-refresh/only-export-components in DescriptionText.tsx	ours	fixed
failed to parse serde attribute (ts-rs)	ours	fixed
hint: to use in all of your new repositories... (git init.defaultBranch)	actions/checkout's internal git init	not ours
[DEP0040] punycode is deprecated	actions/setup-node on Node 24	not ours
[DEP0169] url.parse() is not standardized	actions/setup-node on Node 24	not ours
This project is configured to use pnpm because...	actions/setup-node's own message	not ours

The four third-party ones were checked, not assumed: git init without init.defaultBranch reproduces that hint locally, and the log places it inside the Checkout step of two separate jobs -- this repository's e2e sandbox never runs git init at all. Neither corepack enable nor pnpm install --frozen-lockfile emits either deprecation locally on Node 24.14, and both appear in CI before any of our commands run.

react-refresh/only-export-components

spansToKeyedParts was exported from a file that also exports a component, which breaks fast refresh.

The export was not gratuitous. Renderer tests here are node-only -- no jsdom, no testing-library -- so a component cannot be unit tested, and the keying rule (position-based, so two identical link spans keep distinct keys) has to live somewhere a test can reach. So the fix is a sibling module, not an eslint-disable and not dropping the test. Same split features/skillInstall/lib/installSelection.ts already uses, for the same reason.

DescriptionSpan moves with it -- the type is data the function transforms, not part of the component's API. Every other layer was already importing its own DescriptionSpan from @/services/bridge, so nothing outside this folder changes.

pnpm lint now prints nothing at all.

failed to parse serde attribute

McpParameter::options uses deserialize_with to accept a YAML mapping as well as a list. deserialize_with appears nowhere in ts-rs's source, so it always lands in the unknown-attribute branch: ts-rs warns, then skips it. Skipping is correct -- the field always serializes back as a plain list, so the emitted Array<McpOption> is right. The warning reported a decision that was already correct, on every clippy run.

The only switch is the no-serde-warnings feature, which silences the whole class. That would normally be a bad trade -- it also hides a future serialize_with that genuinely changes the wire shape and would make the TS type silently wrong.

Here it costs nothing, because that signal is already covered by something stronger: the generated bindings are committed, and CI's "Fail on stale generated artifacts" step diffs them. If ts-rs ever emits a different shape for this field, the build fails with an error instead of printing a warning nobody reads. Verified the bindings are byte-identical with the feature enabled.

Verified

pnpm lint (silent), pnpm typecheck, pnpm exec vitest run apps/desktop (619/619), pnpm format:check, cargo clippy --workspace --all-targets (zero warning lines), cargo test --workspace with generated artifacts unchanged, and the desktop suite 20/20 -- DescriptionText is on the MCP install path, whose flow asserts descriptions render as spans rather than raw markup.