Align workflow retry internals with Python source conventions

> Please provide us with the following information:
> ---------------------------------------------------------------

### This issue is for a: (mark with an `x`)
```
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
```

### Minimal steps to reproduce
> Review the plan-authored retry implementation introduced by PR #193 against the newer Python source conventions. Laveesh identified several non-blocking alignment opportunities that were intentionally deferred to avoid expanding an already large feature PR.

### Any log messages given by the failure
> N/A. These are maintainability and standards-alignment follow-ups, not runtime failures.

### Expected/desired behavior
> Address the deferred review suggestions in a focused follow-up:
>
> 1. Evaluate replacing the Durable-persisted Activity outcome `TypedDict` hierarchy and manual validation with strict Pydantic v2 boundary models while preserving exact-key validation and forward compatibility.
> 2. Evaluate using a `StrEnum` for `ActivityFailureKind`, with named members internally and stable string values on the wire.
> 3. Align new source modules with the test-module mirroring convention, including whether coverage from `tests/test_workflow_native_retry.py` should move into `tests/test_activity.py` and `tests/test_native_retry.py`.
> 4. Review retry/error-choreography module docstrings and retain only concise contracts plus narrow correctness gotchas; keep broader design explanations in architecture/FRD documentation.
> 5. Apply the newer guidance to future FRDs by recording the fewest durable decision rows and keeping SDK/error choreography in the design narrative. Do not rewrite or consolidate Decisions 70–80 in `docs/frds/0004-dynamic-workflows.md`, because the Decisions log is append-only reviewed history.

### OS and Version?
> N/A.

### Versions
> Follow-up to PR #193 (`tsuyoshiushio-retry-execution-foundation`).

### Mention any other details that might be useful

> Originating review comments from @larohra:
> - Activity outcome Pydantic boundary models: https://github.com/Azure/azure-functions-agents-runtime/pull/193#discussion_r3961811673
> - `StrEnum` for persisted failure kinds: https://github.com/Azure/azure-functions-agents-runtime/pull/193#discussion_r3961811680
> - Source/test basename alignment: https://github.com/Azure/azure-functions-agents-runtime/pull/193#discussion_r3961811685
> - Concise source docstrings: https://github.com/Azure/azure-functions-agents-runtime/pull/193#discussion_r3961811691
> - Fewer durable FRD decisions: https://github.com/Azure/azure-functions-agents-runtime/pull/193#discussion_r3961811697
>
> The security/correctness suggestions from the same review—redacting invalid input values, rejecting duplicate retry-marker JSON keys, and inspecting nested E2E failure messages directly—were addressed in PR #193 by commit `1edce829`.

> ---------------------------------------------------------------
> Thanks! We'll be in touch soon.

Start by reviewing PR #193 and the linked review comments, then inspect tests/test_workflow_native_retry.py, tests/test_activity.py, tests/test_native_retry.py, and docs/frds/0004-dynamic-workflows.md. Evaluate the five deferred alignment areas: boundary validation, persisted failure-kind values, test mirroring, concise docstrings, and future FRD guidance. Done means the chosen changes preserve exact-key validation and wire compatibility without rewriting Decisions 70–80.

Written by the indexing model from the issue text.