Update deployment-state-caching docs for source AppHost state isolation

## Summary

PR #19709 ("Isolate source AppHost deployment state") changes the on-disk deployment-state layout for **source-file / polyglot AppHosts** (`apphost.cs`, `apphost.ts`, `apphost.py`). The current documentation at [Deployment state caching](https://aspire.dev/deployment/deployment-state-caching/) only describes the legacy model — `~/.aspire/deployments/{AppHostSha}/{environment}.json`, where `AppHostSha` is a directory/project-path hash — and is now incomplete/inaccurate.

This issue tracks a deep-dive doc update. Treat #19709 as the source of truth for the new filesystem layout.

## What changed and needs to be documented

- **Source-specific identity:** source-file AppHosts now derive their deployment-state identity from the *source file* path, not the directory/project hash. Multiple source AppHosts in the same directory no longer share one state identity, so their `{AppHostSha}` folders differ from what `.csproj`-based AppHosts produce. Project (`.csproj`) AppHosts are unchanged.
- **New sidecar files** alongside `{environment}.json`:
- `{environment}.json.migration` — atomic migration snapshot (claimed sections, tombstones, and a legacy-state snapshot).
- `{environment}.json.lock` — cross-process lock file.
- **Legacy state is an immutable read-through fallback.** On first run after upgrade, a source AppHost reads its prior (directory-scoped) state and lazily claims sections into its own sidecar as they are saved. The legacy file is never rewritten or deleted; old files persist by design and are cleaned up naturally (folder deletion / machine rebuild).
- **`--clear-cache` behavior:** for a source AppHost this writes a tombstone (disables legacy fallback) rather than deleting the shared legacy file. The doc currently states it deletes the environment-specific file.
- **CI/CD example is inaccurate for source AppHosts:** the `actions/cache` example keyed on `hashFiles('**/AppHost.csproj')` won't match source-file AppHost identities.

## Notes

- aspire.dev documentation likely lives in a separate repository (e.g. `dotnet/docs-aspire`); confirm the correct target and move/reference this issue accordingly.
- Reference: PR #19709.

Start by reading PR #19709 as the source of truth, then inspect the Deployment state caching page at aspire.dev/deployment/deployment-state-caching/. Confirm whether microsoft/docs-aspire is the target repository. Done means documenting source-file identity, sidecar files, legacy fallback, --clear-cache behavior, and correcting the actions/cache example.

Written by the indexing model from the issue text.