ci: remove notify-downstream dispatcher (downstream cascade is cron now)

[shiba4life]

Why

Both downstream consumers moved off per-merge `repository_dispatch` to a 2-hour cron:

• EdgeVector/fold_db_node#798 — `bump-schema-service.yml` switched to `schedule: "0 */2 * * *"`.
• EdgeVector/schema_service (sibling PR) — `bump-fold-db.yml` made the same switch.

The `fold_db-main-bump` dispatch this workflow fires no longer has a listener once schema_service's PR lands. Removing the dead dispatcher.

Why the cascade moved off dispatch

Per-merge bumps were superseding each other in downstream merge queues before they could land, burning a full CI cycle on PRs that never merged. Hourly-ish batching coalesces multiple upstream merges into one bump cycle.

Trade-offs

• End-to-end cascade lag: ~10-15 min → up to ~4h (2h schema_service hop + 2h fold_db_node hop). Force-flush via:
  • `gh workflow run bump-fold-db.yml -R EdgeVector/schema_service`
  • `gh workflow run bump-schema-service.yml -R EdgeVector/fold_db_node`
• Order-of-merge with the schema_service PR: both orderings are safe. If this lands first, schema_service stops getting dispatches but its own cron isn't active yet → no bumps until it lands (worst case: ~2h gap, same as the new target). If schema_service lands first, this PR's removal is purely cosmetic by then.

Changes

• `.github/workflows/notify-downstream.yml`: deleted.
• `CLAUDE.md` ("Bump cascade (downstream)" section): updated to describe the cron-based cascade, end-to-end lag, and the force-flush commands.

Test plan

• CI passes (workflow + docs only).
• After both this PR and the schema_service PR land, confirm fold_db merges no longer fire `Notify downstream of fold_db main bump` runs (Actions tab — workflow no longer present).
• Confirm a fold_db merge still cascades to fold_db_node within ~4h (via the cron path, not via dispatch).