docs: explain configurable max payload size (payloadStorageMaxPayloadBytes) and fix large payload sample config

[YunchuWang]

Summary

Issue #359 reports that the .NET isolated Durable Functions LargePayload sample fails when PAYLOAD_SIZE_BYTES exceeds ~10 MB, with:

Payload size 10742 KB exceeds the configured maximum of 10240 KB. Reduce the payload size or increase the max payload size limit.

Root cause (verified against the microsoft/durabletask-dotnet SDK source)

• The error is thrown by the AzureBlobPayloads PayloadInterceptor when a payload exceeds LargePayloadStorageOptions.MaxPayloadBytes.
• MaxPayloadBytes defaults to 10 MB (10 * 1024 * 1024 = 10,485,760 bytes; 10,240 KB) and is configurable — not a hard product limit.
• In Durable Functions this cap is set in host.json via payloadStorageMaxPayloadBytes (the sibling of the already-present payloadStorageEnabled / payloadStorageThresholdBytes keys).
• PAYLOAD_SIZE_BYTES is the sample's own generated test-data size — unrelated to the cap. Because the docs never explained the cap or this distinction, the 10 MB limit looked like a hard product limit.

What changed

• samples/durable-functions/dotnet/LargePayload/host.json and .../LargePayloadFanOutFanIn/host.json: add payloadStorageMaxPayloadBytes: 15728640 (15 MiB) so the cap is explicit and demonstrably raised above the 10 MB default.
• Both Durable Functions READMEs (LargePayload, LargePayloadFanOutFanIn): update the host.json snippet, add a "Maximum payload size" section (explains the 10 MB default, the exact fail-fast error, and how to raise the cap), add a table disambiguating PAYLOAD_SIZE_BYTES vs payloadStorageMaxPayloadBytes, and clarify the PAYLOAD_SIZE_BYTES row in the Local settings table.
• samples/durable-task-sdks/dotnet/LargePayload/README.md: note that the SDK's LargePayloadStorageOptions.MaxPayloadBytes has the same 10 MB default and how to raise it in Program.cs.

Note on the original assumptions

While implementing this I verified the repo against the reported problem and found several premises were already resolved by prior PRs (#343 / #344):

• Both host.json files and both READMEs already use the correct payloadStorage* property names (not largePayloadStorage*).
• The FanOutFanIn host.json was not broken — its threshold was already 262144 (256 KiB, the SDK default) and already matched the README.

So this PR focuses on the genuinely-missing piece behind #359: documenting the configurable payloadStorageMaxPayloadBytes cap and disambiguating it from PAYLOAD_SIZE_BYTES.

Fixes #359