fix(clawhub): forward ownerHandle on install to resolve ambiguous slugs (#1284)

[andyst-dev]

Fixes #1284

Problem

The ClawHub skill installer cannot install any skill whose slug is shared by more than one publisher. ClawHub's /api/v1/download returns 409 Conflict for ambiguous slugs unless an ownerHandle is supplied, but ClawHubInstallRequest only carried slug, so POST /api/clawhub/install always failed for e.g. weather (4 publishers).

Fix

Thread an optional publisher handle through the whole install path:

• ClawHubInstallRequest gains owner_handle: Option<String> — accepts both ownerHandle (what the UI/ClawHub api surface uses) and owner_handle, defaulting to None for legacy slug-only installs.
• ClawHubClient::install_with_owner_handle and install_with_options now take an optional owner and build the download URL with &ownerHandle=<handle> appended when present (URL-encoded, empty string treated as absent → identical to current behaviour for unique slugs).
• The clawhub_install route forwards req.owner_handle so the dashboard can disambiguate.

Tests

• crates/openfang-api/src/types.rs: parses both ownerHandle and owner_handle, and legacy slug-only request still defaults to None.
• crates/openfang-skills/src/clawhub.rs: clawhub_download_url builds the plain URL when no owner, appends &ownerHandle= when present, and skips an empty owner.
• cargo build -p openfang-skills -p openfang-api --lib: clean.
• cargo test -p openfang-skills -p openfang-api --lib clawhub: 13 passed (2 new in api, 11 in skills incl. 3 new URL cases).

Note: this is the same direction as my earlier #1274 (closed, never merged) but it also wires the API route, which #1274 omitted — the write-up in #1284's repro (POST /api/clawhub/install returning 409) only works once the route forwards the handle. If a maintainer rejects ambiguity-disambiguation entirely, this can be dropped; otherwise it completes the loop the UI needs.