fix(release): add crate descriptions to unblock crates.io publish

[AprilNEA]

Problem

The Release Build → Publish crates to crates.io job has failed on every release since 0.4.9 (0.4.9–0.4.14, all red). crates.io rejects arcbox-e2e:

error: failed to publish arcbox-e2e v0.4.14 to registry at https://crates.io
Caused by: 400 Bad Request: missing or empty metadata fields: description

cargo publish --workspace uploads in dependency order and aborts on the first failure, so it never gets past arcbox-e2e (6th, alphabetically). xtask has the same missing-description gap and would fail next.

Fix

Give arcbox-e2e and xtask a description, matching every other published workspace member. These are the only two publishable crates missing it.

Heads-up

Because the publish has always died at arcbox-e2e, the crates after it (the app binaries, VM/virtio family, etc.) have never actually been pushed. With this fix, the next release's coordinated cargo publish --workspace will publish the full workspace to crates.io for the first time — which is the workflow's stated intent ("one coordinated publish of the whole workspace"), but it's an irreversible first-time mass publish. If that's not wanted for some members (test/tooling/binaries), the alternative is publish = false / --exclude on those instead — say the word and I'll switch to that.

Pre-existing issue, unrelated to any specific feature; surfaced right after the #346 merge cut 0.4.14.

[pullfrog]

ℹ️ No critical issues — the fix is correct and fully unblocks the publish. Two decisions worth a conscious call before merging (both already flagged in your PR description).

Reviewed changes — a one-line description added to the two publishable workspace crates that were missing it, to get cargo publish --workspace past the crates.io missing metadata fields: description rejection.

• arcbox-e2e gets a description — tests/e2e/Cargo.toml now carries "End-to-end integration tests for the ArcBox container and VM runtime".
• xtask gets a description — xtask/Cargo.toml now carries "Cargo xtask build-automation tasks for the ArcBox workspace".

I verified the completeness claim: grepping every workspace member's Cargo.toml, these two were the only publishable members missing a description. Every other member either already has one or is publish = false (arcbox-fleet-proto, arcbox-fleet-agent). So this PR does fully unblock the coordinated publish — nothing else downstream will hit the same 400.

ℹ️ publish = false is the repo's established pattern for internal crates

The two crates being made publishable here are an end-to-end test harness and a build-automation tool — neither is a library anyone would depend on from crates.io. The repo already marks its other internal crates (arcbox-fleet-proto, arcbox-fleet-agent) with publish = false, so adding descriptions takes these two in the opposite direction from that precedent.

Adding the description is consistent with the workflow's stated "publish the whole workspace" intent, and guest/arcbox-agent (a binary crate) is already published, so there's precedent both ways. This is a judgment call only you can make.

Technical details

# `publish = false` vs. add-description for internal crates

## Affected sites
- `tests/e2e/Cargo.toml:9` — `arcbox-e2e`, an integration-test crate
- `xtask/Cargo.toml:9` — `xtask`, build-automation tooling
- Precedent: `fleet/arcbox-fleet-proto/Cargo.toml`, `fleet/arcbox-fleet-agent/Cargo.toml` (`publish = false`)

## Required outcome
- Decide, per crate, whether it should exist on crates.io at all. Either outcome unblocks the release job: `cargo publish --workspace` skips `publish = false` members just as cleanly as it accepts ones with a description.

## Open questions for the human
- Should an e2e test crate and an xtask helper be consumable from crates.io, or are they internal-only like the fleet crates? If internal-only, `publish = false` matches existing convention and avoids reserving/maintaining two crates.io names for artifacts no external user consumes.

ℹ️ This unblocks the first-ever full-workspace publish — irreversible

Because the publish has died at arcbox-e2e on every release since 0.4.9, every member ordered after it alphabetically has never actually been pushed to crates.io. The next release will publish all of them for the first time in one coordinated run, and crates.io publishes cannot be undone (only yanked, which does not free the name or remove the source).

Technical details

# First-time mass publish of the full workspace

## Affected sites
- `.github/workflows/release.yml:94` — `cargo publish --workspace --exclude arcbox-hv --no-verify --locked`

## Required outcome
- Confirm that publishing the entire workspace (app binaries, VM/virtio family, rpc crates, guest agent, and now the e2e + xtask crates) to crates.io is genuinely intended, since the first successful run is irreversible.

## Open questions for the human
- Are there members that should NOT be on crates.io permanently (binaries like `arcbox-daemon`/`arcbox-cli`, the guest agent, tooling)? If so, `publish = false` / `--exclude` on those is the moment to decide, before the names are claimed. If "publish everything" is the deliberate policy, no action needed.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[greptile-apps]

Greptile Summary

This PR adds missing crates.io metadata for two workspace crates. The main changes are:

• Added a description for arcbox-e2e.
• Added a description for xtask.

Confidence Score: 5/5

Safe to merge; the changes are limited to package metadata descriptions.

Only two Cargo manifest description fields were added, with no runtime code or build logic changes.

T-Rex Logs

What T-Rex did

• Compared crate-descriptions between the base and head commits, observed that before there were no description lines and arcbox-e2e and xtask checks failed, then after changes added non-empty descriptions and both checks passed.
• Checked publishable descriptions for arcbox-e2e and xtask, confirming that the before state reported MISSING_PUBLISHABLE_DESCRIPTION, and the after state shows descriptions present with none missing.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(release): add crate descriptions to ..." | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4faaaccd25

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Exclude the project-local xtask crate from publishing

In the release workflow I inspected, .github/workflows/release.yml runs cargo publish --workspace --exclude arcbox-hv --no-verify --locked, and cargo publish --help confirms --workspace publishes all workspace packages while --exclude only skips named packages. Cargo’s publishing docs also state that crates.io names are first-come-first-serve and cannot be reused once taken; xtask is already an unrelated crate on crates.io, so after this description lets Cargo get past local metadata validation, the next release will still abort at xtask unless the ArcBox token somehow owns that unrelated crate. For this repo-local automation package, add publish = false here or exclude it in the workflow instead of making it publishable.

Useful? React with 👍 / 👎.