ci: rust-cache was caching nothing, it needs workspaces

[MattJackson]

rust-cache was caching nothing here

Swatinem/rust-cache@v2 was used with no workspaces: input. The action looks for one Cargo workspace at $GITHUB_WORKSPACE, and nothing is checked out there: every actions/checkout in these jobs uses path:. The action logged "could not find Cargo.toml" and CARRIED ON WITHOUT FAILING, so the job rebuilt everything from scratch on every run while the log said the cache step succeeded. That is the worst shape a cache misconfiguration can take: it costs full build time on every run and reports success.

Every Cargo workspace the job actually builds is now named. Where the job also builds the sibling busbar checkout, that is listed too, and it matters more than the plugin's own: busbar-plugin-pack plus a full release build of busbar is by far the larger of the two.

Deliberately left alone

Checked every workflow in this repo that uses Swatinem/rust-cache, not just the ones changed. A job whose Cargo workspace genuinely is at the checkout root needs nothing and got nothing, rather than a workspaces: . that would be pure noise. headroom-hook/.github/workflows/docker.yml is one such case (its checkout has no path:), and headroom-hook/.github/workflows/docker-bundle.yml already carried a correct workspaces: busbarAI.

Part of a fleet sweep

Same fix applied across the first-party plugin repos, and to the reusable plugin-ci.yml in core (GetBusbar/busbar#58), which had the same defect and reaches every plugin repo at once.

[MattJackson]

Verified on real runners, not assumed

Before, from run 31282480013 (unfixed config, ci/consumer-verification)

The cache step's own log, verbatim:

Error: The process '/home/runner/.cargo/bin/cargo' failed with exit code 101
  commandFailed: {
    command: 'cargo metadata --all-features --format-version 1 --no-deps',
    stderr: 'error: could not find `Cargo.toml` in `/home/runner/work/store-valkey/store-valkey` or any parent directory'
  }
Cache Configuration
  Workspaces:
      /home/runner/work/store-valkey/store-valkey
  Cache Paths:
      /home/runner/.cargo/bin
      /home/runner/.cargo/.crates.toml
      /home/runner/.cargo/.crates2.json
      /home/runner/.cargo/registry
      /home/runner/.cargo/git
      /home/runner/work/store-valkey/store-valkey/target

and then, on the very next line, Cache restored successfully. That is the whole defect in one screen. The single configured workspace is the checkout root, where there is no Cargo.toml because every checkout uses path:. The only target path it cached is a directory that does not exist. Neither real target directory was ever cached. The step reported success and the job was green.

After, from run 31283264799 (this branch)

with:
  workspaces: store-valkey-repo/store-valkey
             busbarAI
Cache Configuration
  Workspaces:
      /home/runner/work/store-valkey/store-valkey/store-valkey-repo/store-valkey
      /home/runner/work/store-valkey/store-valkey/busbarAI
  Cache Paths:
      ...
      /home/runner/work/store-valkey/store-valkey/store-valkey-repo/store-valkey/target
      /home/runner/work/store-valkey/store-valkey/busbarAI/target

The could not find Cargo.toml error is gone and both real target directories are now cached.

Warm run, 31283395287

Cache hit for: v0-rust-migrate-destructive-wipe-test-Linux-x64-e8b3ee54-9dc4cd49 followed by Cache restored successfully, with no error.

The timing number, stated honestly

Cold 26s, warm 22s on the cargo test step. That is a real but modest delta, and it would be misleading to present it as the headline. Two reasons it is small here, both worth stating rather than glossing:

1. The "cold" run was not truly cold. The job-id cache key is unchanged by this PR, so that run already restored a populated ~/.cargo/registry saved by earlier runs of the BROKEN config. The registry was always being cached; only the target directories were not. So this delta measures the target-dir contribution alone.
2. This particular job builds very little: one small crate and a --ignored single test. The jobs where the missing target cache actually costs real money are the ones that build busbar itself (release.yml, and core's reusable plugin-ci.yml), and those run on tags rather than on pushes, so they are not cheaply measurable from a PR.

The load-bearing evidence is therefore the structural before/after above: the workspaces now resolve, the error is gone, and the target directories are in the cache paths where previously a nonexistent directory was. The timing is consistent with that and is not, on this job, dramatic.

Note on this PR's red check

The ci / build, test, clippy, fmt, signoff job is red on PUBLIC-HYGIENE GATE, which is pre-existing on main and unrelated to this change. Its fix is open separately as #5. Confirmed by running the lint directly: main reports hits and FAILED, the #5 branch reports 0 hit(s), 0 allowed and passes. Merge #5 first and this goes green.