docs: document the CORS requirement for module scripts (#326)

Adds a Notes/CORS section to the cdn-aliyun and cdn-s3 READMEs: once the
frontend loads as ES modules (apache/answer#1567), a CDN origin must
send Access-Control-Allow-Origin for the site origin or the browser
refuses to run the entry script and pages load without JavaScript. Each
section carries a minimal provider-native CORS rule (OSS XML for Aliyun,
S3 JSON for AWS) plus a CloudFront note covering origin-request and
response-headers policies. Section shape follows the existing Notes
convention in storage-s3's README. Requested by review on
apache/answer#1567; companion to it, best merged with or after.

cdn-aliyun/README.md

diff --git a/cdn-aliyun/README.md b/cdn-aliyun/README.md
index 3706386..7d3a974 100644
--- a/cdn-aliyun/README.md
+++ b/cdn-aliyun/README.md
@@ -15,4 +15,26 @@
 - `Access Key Id` - AccessKeyID of the AliCloud OSS storage
 - `Access Key Secret` - AccessKeySecret of the AliCloud OSS storage
 - `Visit Url Prefix` - Prefix of access address for the CDN file, ending with '/' such as https://static.example.com/xxx/
-- `Max File Size` - Max file size in MB, default is 10MB
\ No newline at end of file
+- `Max File Size` - Max file size in MB, default is 10MB
+
+### Notes
+
+#### CORS
+
+A `type="module"` script is always fetched in CORS mode. If `Visit Url Prefix` points at a different origin than the site itself, the bucket must return `Access-Control-Allow-Origin` for that origin, or the browser blocks the script and the page loads with no JavaScript. The request for the script itself still returns 200 and server-rendered content still appears, so the page can look populated while nothing is interactive.
+
+Add a CORS rule to the bucket (OSS console CORS settings, `ossutil`, or the `PutBucketCors` API). A minimal rule that lets the site read static assets, no credentials required:
+
+```xml
+<CORSConfiguration>
+  <CORSRule>
+    <AllowedOrigin>https://your-answer-site.example.com</AllowedOrigin>
+    <AllowedMethod>GET</AllowedMethod>
+    <AllowedHeader>*</AllowedHeader>
+    <ExposeHeader>ETag</ExposeHeader>
+    <MaxAgeSeconds>3600</MaxAgeSeconds>
+  </CORSRule>
+</CORSConfiguration>
+```
+
+Replace `https://your-answer-site.example.com` with the origin the site is actually served from. `GET` is the only method this plugin needs, and no `Access-Control-Allow-Credentials` handling is required since the request carries no cookies or auth headers.
\ No newline at end of file

cdn-s3/README.md

diff --git a/cdn-s3/README.md b/cdn-s3/README.md
index 7dc3f19..03ae3fb 100644
--- a/cdn-s3/README.md
+++ b/cdn-s3/README.md
@@ -16,4 +16,27 @@
 - `Access Key Secret` - AccessKeySecret of the S3
 - `Access Token` - AccessToken of the S3
 - `Visit Url Prefix` - Prefix of access address for the static file, ending with '/' such as https://static.example.com/xxx/
-- `Max File Size` - Max file size in MB, default is 10MB
\ No newline at end of file
+- `Max File Size` - Max file size in MB, default is 10MB
+
+### Notes
+
+#### CORS
+
+A `type="module"` script is always fetched in CORS mode. If `Visit Url Prefix` points at a different origin than the site itself, the bucket must return `Access-Control-Allow-Origin` for that origin, or the browser blocks the script and the page loads with no JavaScript. The request for the script itself still returns 200 and server-rendered content still appears, so the page can look populated while nothing is interactive.
+
+Add a CORS configuration to the bucket (S3 console, Permissions tab, or the `PutBucketCors` API). A minimal rule that lets the site read static assets, no credentials required:
+
+```json
+[
+  {
+    "AllowedOrigins": ["https://your-answer-site.example.com"],
+    "AllowedMethods": ["GET"],
+    "AllowedHeaders": [],
+    "ExposeHeaders": []
+  }
+]
+```
+
+Replace `https://your-answer-site.example.com` with the origin the site is actually served from.
+
+If `Visit Url Prefix` points at a CloudFront distribution in front of the bucket rather than the bucket directly, the bucket's CORS rule alone is not enough. CloudFront only forwards the browser's `Origin` header to S3, and only caches per origin, when its cache or origin request policy says to; otherwise it can cache one origin's CORS response and serve it to every other origin. Either attach the managed origin request policy `CORS-S3Origin` (or a custom policy that includes `Origin` in the cache key) so CloudFront forwards and caches per origin, or attach a response headers policy with its own CORS configuration so CloudFront adds `Access-Control-Allow-Origin` itself at the edge.
\ No newline at end of file