feat: skill registry points at the 10 current skills in brightdata/skills

[nirsha-brd]

What

Replaces the skill installer registry with the 10 skills that brightdata/skills ships after the v2 stack (#32, #34, #35, #36): agent-onboarding, scrape, datasets, fetch, search, browser, billing, brightdata-cli, brightdata-mcp, brightdata-sdk.

Two files changed: src/utils/skill-installer/brightdata-skills.ts (the registry, names, descriptions and URLs in the existing entry format) and src/commands/scrape.ts (one added line, see below). No other code touched.

Why

The v2 stack makes brightdata/skills ship exactly these 10 skills and removes the 17 retired folders. The current registry lists 6 names that will no longer exist on main (data-feeds, bright-data-mcp, bright-data-best-practices, design-mirror, python-sdk-best-practices, scraper-builder). Each of those fails at install time with a per-skill fetch error. This PR points the menu at the real set.

Verified

• tsc compiles the branch clean.
• Ran the built binary:
  • skill add nonsense-name prints the clean unknown-skill error listing the 10 names, exit 1.
  • skill add datasets (in the registry, not on skills main until the stack merges) fails as a contained per-skill 404 with a clean summary, no crash, exit 1.
  • skill add scrape performs a real install across 10 detected agents, exit 0.
• Grepped the whole dist: only the skill-add path reads the skills repo, so the registry change cannot affect any other command.

Sequencing

Safe to merge before or after the skills stack. Before: the not-yet-published names fail with the contained per-skill error shown above. After: all 10 install. Ideal order is skills first, then this, then a release.

Also in this PR

.alias('fetch') on the scrape command, so bdata fetch <url> works as the same Web Unlocker call. bdata scrape keeps working forever. Verified: no name collision with any command, tsc clean, help shows scrape|fetch, full vitest suite green minus one pre-existing ipc flake that fails identically without this change, and an org-wide code search shows nothing anywhere invokes bdata fetch today, so the alias cannot break any consumer.