feat(web): make individual settings searchable, dedupe composer skills

[rynfar]

Three upstream adoptions around settings search and the composer skill menu.

• #8881 make WSL settings searchable — applied clean
• #8831 search individual settings by detail
• #8043 dedupe skills in composer menus

Settings search now matches on a setting's own title and terms rather than only
its panel, and the panel scrolls to and opens the matched control — including
expanding a collapsed Advanced section.

Carve-outs

#8831 routes several titles through a searchableSetting(...) registry lookup.
Two of those registry entries are product copy that arrived branded: the
t3-connect entry's title and the "Publish agent activity" description. The
compatibility id t3-connect is kept as-is; the title and description now say
Pylon Connect.

#8831's hunk for the composer-capacity row would have replaced Pylon's
"Subscription capacity in the composer" SettingsRow outright — that row is
Pylon's and upstream has no equivalent. Kept, with upstream's new id prop
applied to the row that actually follows it.

Upstream added searchTerms to the legacy-plan-mode entry, but Pylon's catalog
orders that entry differently, so the hunk landed as a second copy rather than an
edit — 55 entries, 54 unique ids. settingsSearch.test.ts's uniqueness assertion
caught it. The duplicate is removed and the terms folded into Pylon's entry.

#8043's mobile hunk is written against an inline command-item builder that Pylon
has since extracted into buildComposerCommandItems. Taking it would have
reverted that refactor. Pylon's structure is kept and the actual fix applied where
the code now lives: the trigger.kind === "skill" path was still filtering
enabled skills without deduping, so a skill defined in two directories showed a
duplicate row. It now calls dedupeProviderSkillsByName.

ProviderSettingsPanel.environment.test.tsx gained upstream's findAdvancedPanel
and flushEffects helpers alongside Pylon's isAdvancedTrigger. Upstream's finder
matches on className="mt-1" plus a boolean open prop, which Pylon's
<Collapsible> satisfies, so both work against Pylon's markup.

Verification

@t3tools/web, @t3tools/mobile, and @t3tools/client-runtime typecheck clean.
Lint clean. 144 settings tests, 171 mobile thread-feature tests, 13
client-runtime skill tests passing. No T3 Code or T3 Connect in any added line.

Unrelated and left alone: a stale "T3 Connect" mention in a Sidebar.tsx code
comment predates this branch.

Model: Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.6 KiB	13.7 KiB	+180 B (+1.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.8 KiB	+171 B (+2.5%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.2 KiB	58.7 KiB	+1.5 KiB (+2.6%)	66.4 KiB	✅
Codex	Live turn messages	10	11	+1 (+10.0%)	21	✅
Claude	Total thread wire	13.6 KiB	13.8 KiB	+187 B (+1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.8 KiB	+184 B (+2.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.1 KiB	59.5 KiB	+1.5 KiB (+2.5%)	66.4 KiB	✅
Claude	Live turn messages	10	11	+1 (+10.0%)	21	✅

Baseline: a509639 · PR result: ed613f1 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.