[Bug]: Invalid checkpoint token misclassified as execution failure (message case mismatch)

### Expected Behavior

When the service rejects a checkpoint call with `InvalidParameterValueException` because the checkpoint token is stale (a newer invocation superseded this one), the SDK should classify the error as **retryable** (invocation scope). The current invocation ends, and the service starts a fresh invocation with a fresh token. The execution itself continues.

### Actual Behavior

The SDK classifies the error as **non-retryable** (execution scope). So a stale checkpoint token fails the whole durable execution every time.

### Root Cause

The classifier matches the error message with a case-sensitive prefix check against `"Invalid Checkpoint Token"`. The service emits `"Invalid checkpoint token"` (lowercase `c` and `t`). The prefix check never matches. The error falls through to the non-retryable arm.

Service constant (`DurableExecutionsServiceSharedLib`, `ValidationErrorMessages.java` line 86, internal):

```java
public static final String INVALID_CHECKPOINT_TOKEN = "Invalid checkpoint token";
```

SDK constant (`src/client.rs`):
https://github.com/aws/aws-durable-execution-sdk-rust/blob/60ea9cf07652872083f0e6dac9b4761a801168ea/src/client.rs#L248

```rust
const STALE_TOKEN_MESSAGE_PREFIX: &str = "Invalid Checkpoint Token";
```

Used in `classify_checkpoint_error` via `m.starts_with(STALE_TOKEN_MESSAGE_PREFIX)`. The comment on the constant cites the Java SDK's `DurableApiErrorClassifier`, which has the same defect.

### Steps to Reproduce

1. Have the service return an `InvalidParameterValueException` whose message starts with `Invalid checkpoint token` (the real service message).
2. Pass it through `classify_checkpoint_error`.
3. Observe `is_retryable()` is false. `context.rs` `checkpoint_failure_unrecoverable` then records a terminal FAIL and fails the execution.

Any existing test that constructs the error with `"Invalid Checkpoint Token..."` matches the SDK constant rather than the service constant and so cannot catch this.

### Proposed Fix

1. Change the SDK constant to `"Invalid checkpoint token"` so it matches the service.
2. Consider a case-insensitive comparison to protect against future drift.
3. Update the tests to use the real service message.

### Related

Same defect exists in the other SDKs; each has its own issue. Sibling links are in a comment below.

### SDK Version

main (60ea9cf)

Start in src/client.rs at STALE_TOKEN_MESSAGE_PREFIX and classify_checkpoint_error, then inspect context.rs at checkpoint_failure_unrecoverable and the existing classifier tests. Run the relevant test suite with an error message beginning "Invalid checkpoint token". Done means the real service message is classified as retryable and the tests no longer rely on the incorrect capitalization.

Written by the indexing model from the issue text.