Evaluate ci-battery-pack for CI workflow generation

Suggested by @jlizen in review: https://github.com/aws/aws-durable-execution-sdk-rust/pull/4#discussion_r3806800407

## Question

[ci-battery-pack](https://crates.io/crates/ci-battery-pack) generates a Rust CI workflow with pinned action SHAs and the project's MSRV. It's a generator, so nothing from the crate runs during CI — the output is reviewable YAML we commit. Currently 0.1.6. @jlizen is its principal contributor and raised it as a "might be useful", not a recommendation.

Worth a look before we hand-wire the checks in #39, but no decision implied either way.

## What would settle it

- Generate a workflow on a scratch branch and diff against the current `ci.yml`.
- Does the output keep what we rely on — the `msrv` job, `scripts/check-msrv-consistency.sh`, `cargo deny`, `scripts/check-direct-deps.sh`? If it replaces `ci.yml` wholesale we'd be hand-merging, which reduces the saving.
- Does it emit `cargo-check-external-types`? That's the check that catches #37 and #38, so if not, we wire it ourselves regardless.
- Pins are fixed at generation time. What keeps them fresh, and is that maintenance we want?

Outcome may be "not now" — recording the reasoning either way is the point.

Generate a ci-battery-pack workflow on a scratch branch and diff it against ci.yml. Check whether the output preserves the msrv job, scripts/check-msrv-consistency.sh, cargo deny, scripts/check-direct-deps.sh, and cargo-check-external-types; then record whether adopting it reduces work and how its pinned actions would stay fresh.

Written by the indexing model from the issue text.