feat(run): make hm run --cloud register/create pipelines automatically

[markovejnovic]

What

Makes hm run --cloud "just work" after hm init — no manual dashboard registration.

• Auto-create on first run. On a pipeline_not_found, the driver resolves-or-creates the pipeline and submits the build by its org-global slug (submit_build), bypassing repo-identity discovery (which can't see API-created pipelines). New by-slug submit path in CloudBackend, gated by RunRequest.cloud_pipeline_slug.
• Works with no git remote. Falls back to interactively registering: pipeline name = the in-repo @hm.pipeline("…") slug; prompts the user for the repo name (owner/repo, default = directory name) only when a create is actually needed; persists [cloud] pipeline = "<slug>" to .hm/config.toml so later runs submit by slug with no prompt. CI/non-TTY auto-registers under the directory name.
• New config field CloudConfig.pipeline: Option<String>.
• Error-doctrine cleanup: removed the dead docs https://harmont.dev/docs/errors/<code> URLs (all 404) from every error, and dropped the misleading "check that the Docker daemon is running" hint from the overloaded BackendError::Local arm.

Resolution flow (cloud)

persisted [cloud] pipeline?            -> submit by that slug
has git remote?                        -> submit_repo_build; on 404 -> get-or-create by source slug -> submit by slug
no remote, not registered?             -> prompt repo name -> create_pipeline{ name=<source-slug>, repository=<repo>, repo_name=<repo> } -> persist -> submit by slug

Backward compatibility

A normal connected-repo hm run --cloud (has remote, no persisted pipeline) is unchanged — it still uses the repo-identity submit and only diverges on an actual pipeline_not_found. CloudConfig.pipeline is Option/#[non_exhaustive] and defaults to None, so existing .hm/config.toml files deserialize unchanged; cloud_pipeline_slug is internal (not serialized).

Testing

• Unit tests for the pure pieces: is_missing_pipeline, parse_default_branch, build_create_pipeline_request (Some/None), persist_project_pipeline (creates + preserves existing keys).
• Network-gated orchestration (register_remoteless_pipeline / resolve_or_create_cloud_pipeline) verified by review — no HTTP-mock harness in this crate.
• cargo build / cargo clippy --workspace --all-targets / cargo test --workspace / cargo fmt --check all green.

Server-contract assumptions (need live validation)

Two things only a live cloud run can confirm, both surfacing a clear error if wrong:

1. Newly-created pipelines must default to allow_manual = true (else the by-slug build is rejected).
2. create_pipeline must accept a non-URL repository string for a remoteless/manual pipeline.