… hanging

Two independent faults, both measured.

1. Standalone build was impossible. Cargo.toml carried
   gitbot-shared-context = { path = "../../shared-context" }, which
   resolves only inside the gitbot-fleet monorepo layout, so a bare
   clone died at dependency resolution:

     failed to load source for dependency `gitbot-shared-context`
     failed to read /home/runner/work/shared-context/Cargo.toml

   That is why db-checks, cargo-audit and Rust CI were all red — CI
   checks out this repo alone.

   hyperpolymath/gitbot-fleet is public and contains shared-context/
   with package gitbot-shared-context v0.1.0, so the dependency now
   points there, pinned to a rev. Cargo locates a package in a repo
   subdirectory automatically, so this works from a bare clone and
   from the monorepo alike. Fleet developers who want their local
   working copy can add a [patch] entry or a .cargo/config.toml paths
   override.

   Note for maintenance: Dependabot does not bump rev-pinned git
   dependencies, so the rev needs occasional manual attention.

2. publish.yml ran a bare `cargo test --lib`, which was measured
   hanging past 20 minutes (exit 124) — sitting in the release path
   behind only a 15-minute job timeout. Suites are now named
   explicitly, and the resulting gap is declared in the step summary on
   every run. An exclusion nobody can see is indistinguishable from
   coverage, so it is restated rather than silently dropped.

Also deletes instant-sync.yml and push-email-notify.yml. Both were
disabled_manually; a disabled workflow file still reads as "we have
this gate", so removing them is more honest than leaving them dark.

Verified: cargo fetch resolves the dependency graph (exit 0), which
was the exact operation that previously failed; cargo metadata parses;
publish.yml strict-parses as YAML.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Completes the sweep. Both were displayed by path rather than name in run
history — the tell that GitHub never parsed them — and both had a
distinct cause, neither of which was YAML validity.

boj-build.yml gated its job on

    if: ${{ vars.BOJ_SERVER_URL != '' || secrets.BOJ_SERVER_URL != '' }}

but `secrets` is not an available context in a job-level `if:` (only
github, needs, vars and inputs are). The invalid expression made the run
graph fail to build, so the workflow never ran. It now gates on vars
only; the secret is still consulted inside the step, so behaviour is
unchanged when the variable is set.

e2e.yml declared no jobs at all — every job was commented out, leaving a
file that GitHub must reject, since a workflow requires at least one
job. It has been deleted rather than left in place: a workflow file that
cannot run is a gate that exists only on paper. The commented-out
intent remains in git history if it is ever revived.

Verified: boj-build.yml parses with 1 job.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>