fix(hub): target the running profile in copyable commands

[hongkong7530]

What changed

The install command the hub shows and copies was pinned to --profile web, and the catalog
stamps that same placeholder onto every entry it publishes. A host serving a different profile
therefore handed the user a command for the wrong profile — DSH Desktop runs the desktop
profile, so pasting a copied command installed the plugin into web. The uninstall command
omitted --profile entirely, which the official CLI rejects outright.

Measured against the live catalog: 13448 of 13448 entries carry dsh plugin --profile web add …
in both install.command and install.githubCommand, and none names another profile.

• retargetProfile() rewrites only the catalog's blanket placeholder, using the profile reported
  by GET /dsh-plugin-hub/env.
• A profile a plugin pins for itself is preserved — CLI-only plugins such as dsh-tui genuinely
  need --profile dsh-tui, which cannot be inferred from the package name.
• uninstallCommandOf() builds the uninstall command with the profile, since --profile is a
  required option.
• Before /env answers, no profile is invented: the generated command omits --profile and the
  UI shows a <profile> placeholder rather than naming a possibly-wrong one.
• The server's "already installed" remedy text also printed a profile-less dsh plugin remove …;
  it now names the profile too.

Why

Copying a command is the documented escape hatch when an in-app install fails, and for CLI-only
plugins it is the only path. On Desktop it silently targeted the wrong profile.

Verification

• npm run check — typecheck (client/server/test), tests, and build all pass.
• New tests/install-command-profile.test.ts (5 tests) covers the rewrite, a pinned profile,
  the unknown-profile case, and both generated commands.
• tests/catalog.test.ts previously asserted the hardcoded web for a generated command; it now
  passes the profile explicitly.
• Two tests in tests/probe.test.ts fail in this environment on main as well (they exercise a
  real git handshake through a non-existent proxy and a curl TLS-revocation fallback); they are
  unrelated to this change and fail identically on a pristine checkout.
• End-to-end on DSH Desktop 0.2.0-rc.2: the running host served the rebuilt bundle, and the
  generated commands resolve to dsh plugin --profile desktop ….

Notes

This targets the community hub only. A separate and unrelated issue exists in DSH core:
reconcile() in @deepseek-ai/dsh-plugin-manager skips dependencies that were already present
before the run, so an install interrupted between pnpm writing package.json and reconciliation
leaves the package installed but absent from dsh.profile.bundles — it never loads, and re-adding
it does not repair the state. Reproducible by killing the install around 3s in; remove + add
fixes it. Happy to file that separately if useful.

[hongkong7530]

i have done a better vision，so later i will push something new