… URL parsing

Closes #489 (security hardening umbrella), #490 (detached HEAD fallback),
#491 (fetch_and_rebase swallows symbolic-ref error).

## Security

- Strip GIT_TRACE / GIT_TRACE_CURL / GIT_CURL_VERBOSE / GCM_TRACE etc.
  on every Command::new("git") that talks to a remote. Without this,
  CI that sets GIT_CURL_VERBOSE=1 (or a Datadog APM agent that injects
  GIT_TRACE_CURL transparently) causes git to dump the Authorization
  header to stderr, which ferrflow then forwarded into anyhow::Error
  display strings. Added a token-pattern scrubber on stderr propagation
  as a defense in depth (masks ghs_/ghp_/gho_/ghu_/glpat_/github_pat_).
- Switch credential helper escaping from double-quote escaping to
  single-quoted sh literals with proper ' -> '\'' encoding. A token
  containing dollar, backtick, semicolon, ampersand no longer reaches
  sh -c as code. Added unit test with an evil token.
- Hook subprocesses now env_remove GITHUB_TOKEN / FERRFLOW_TOKEN /
  GITLAB_TOKEN before exec. Bot mode sets these process-wide so git
  picks them up via credential helper, but a malicious hook can no
  longer exfiltrate the token by echoing the env var.
- extract_host (src/forge/mod.rs) now strips userinfo (user[:pwd]@)
  before returning the host. Previously a remote like
  https://attacker.com#@github.com/owner/repo resolved host to
  "attacker.com#@github.com" which downstream forge construction
  could mis-route the token to.
- TS config loader writes its wrapper into tempfile::tempdir() instead
  of the directory of the user .ts. Closes a symlink TOCTOU where
  a cohabiting process could create .ferrflow-loader.mjs as a symlink
  to ~/.bashrc before ferrflow fs::write follows it.

## Bug fixes

- resolve_current_branch (src/git/repo.rs) no longer falls back to
  GITHUB_REF_NAME when the CI is in detached HEAD mode and that env
  var contains a tag name. Only use GITHUB_REF when it starts with
  refs/heads/. Same logic for CI_COMMIT_REF_NAME (skip when
  CI_COMMIT_TAG is set).
- fetch_and_rebase (src/git/push.rs) no longer silently rewrites a
  branch ref when symbolic-ref fails. Previously a detached HEAD
  state caused .ok().unwrap_or_default() to compare empty to the
  target ref, dropping into a destructive update-ref plus checkout -f
  that could overwrite the user local state. Now hard-fails with a
  clear HEAD is detached error and an actionable hint.
- formats/gomod.rs no longer falls through to the process CWD when
  file_path.parent() is the empty Path.

## Tests

- 514 lib tests plus 616 bin tests pass, cargo clippy -D warnings clean
- New tests: single-quote-escape an evil token, strip GIT_TRACE env

The bare ureq::get / ureq::post helpers create a fresh Agent (and TLS
handshake) per call. A 50-pkg release does ~150 HTTPS round-trips
against api.github.com (create_release × N, find_draft_release × N,
publish_release × N, plus comment + auto-merge for PR mode) — each
paying a fresh handshake.

Build one Agent in build_forge() and store it on GitHubForge /
GitLabForge. Subsequent calls reuse it via HTTP keep-alive. Expected
2-8 seconds saved on a 50-pkg release; smaller wins on single-pkg.

Closes #509.

…ns (#517)

First half of #514. Closes the lock concern; the checkpoint/resume
piece stays open (heavier design, separate PR).

## Problem

Two concurrent ferrflow release invocations on the same repo (typical
scenario: manually-triggered release racing the cron-driven
auto-release workflow, or two CI runners on the same commit) competed
on git refs. Observed symptoms: non-fast-forward rejects, half-pushed
tag sets, draft releases created twice.

## Fix

New src/monorepo/run/lock.rs: RAII lock guard backed by
.git/ferrflow.lock created via O_CREAT|O_EXCL. Atomic. Released on
drop, including panic unwind.

Acquired at the top of run_release_logic for non-dry-run only.
Read-only commands (check, status, version, tag) are not affected.

## Stale lock recovery

A lockfile older than STALE_LOCK_TTL (30 min, longer than any realistic
release) is treated as orphaned (process crashed without releasing)
and taken over with a warning. Beyond TTL the user can also
force-unlock manually by deleting the file; future PR may expose this
via --force-unlock CLI flag.

## Tests

- 6 unit tests in src/monorepo/run/lock.rs::tests:
  - acquire on clean repo succeeds
  - drop removes lockfile
  - second acquire fails while first held
  - force unlock takes over active lock
  - missing .git dir errors out cleanly
  - lockfile content starts with PID
- 521 lib + 635 bin tests pass overall
- cargo clippy -D warnings clean

## Out of scope

The checkpoint/resume mechanism from #514 (write release-state.json at
each step, resume if interrupted) is deferred — needs separate design
review around atomic write + invalidation rules. Issue stays open.