fix: load with dsh-settings >= 0.1.2 (SettingsProvider wiring, drop removed helpers)

[Julyves]

What & why

dsh (@deepseek-ai/dsh) 0.1.2-rc.1 no longer boots any profile that bundles this plugin:

Error: plugin tree failed to load ... The requested module '@deepseek-ai/dsh-settings'
does not provide an export named 'installSettingsSection'
SyntaxError: ... @bocha-ai/dsh-web-search-bocha/lib/index.js:3

@deepseek-ai/dsh-settings removed the free functions installSettingsSection /
settingsNamespace starting in 0.1.2-alpha.2 (verified against published
packages: present in 0.1.1-rc.2, gone in 0.1.2-alpha.2). Because src/index.ts
imported them by name, the plugin module itself throws at ESM instantiation and
the whole cordis include entry fails — boot is blocked, not just the settings UI.

Change

src/index.ts no longer imports the removed helpers. It now wires the section
through the public settings service, replicating exactly what the removed
installSettingsSection helper did internally:

• ctx.inject(['settings'], ...) to attach while a settings service is mounted
• settings.register(ns, Config, { base: config }) with the composition entry
  as the base layer
• the registered scope.get() becomes the live source; on service absence,
  disposal or reload the code falls back to the composed entry
• each search reads a fresh snapshot from the source (current())

No behavioural change: user edits still override the bundle config, and the
provider keeps working when no settings service is present.

Compatibility: these service APIs (inject, register, scope.get/watch) exist
on every dsh-settings release the old helper depended on, so the plugin loads on
both the pre-0.1.2 harness cores and 0.1.2-rc.1+.

Version & dev deps

• Bump version to 0.1.1 for a patch release of this fix.
• Pin @deepseek-ai/dsh-{credentials,launch-environment,settings,web}
  devDependencies to 0.1.2-rc.1. The previous caret prerelease ranges resolve
  to 0.1.3-alpha builds whose siblings declare stable-style ranges (e.g.
  @deepseek-ai/dsh-brand >=0.1.2 <0.2.0-0) that no published prerelease
  satisfies, so a fresh pnpm install fails outright. Pinning reproduces the
  core this fix targets and makes local build/test deterministic.

Verification

• pnpm build — tsc typecheck clean, tsdown bundle succeeds
• pnpm test — 32/32 pass (settings-credentials, loader-composition, bocha)
• Note: tsconfig.json extends ../tsconfig.base.json, which is not shipped in
  the repo; standalone builds need that sibling file (I created one locally to
  verify — not part of this PR).

Release request: after merge, please npm publish from main and tag v0.1.1
(no CI/release automation exists in this repo).