Minor copy, diagram, and instruction fixes

Author: simonkurtz-MSFT

.github/agents/apim-sample-creator.agent.md

@@ -36,7 +36,7 @@ You are the specialist for adding new samples to the APIM Samples repository.
 3. Update `docs/index.html` sample cards and the JSON-LD `ItemList` entry.
 4. Update `assets/APIM-Samples-Slide-Deck.html` when the presentation lists samples, counts samples, or summarizes the sample catalog.
 5. Update `tests/Test-Matrix.md` so the new sample appears in the compatibility test matrix.
-6. Update compatibility diagrams or related assets when the supported infrastructure matrix changes visually.
+6. Update `assets/diagrams/Infrastructure-Sample-Compatibility.svg` to add a new row for the sample in alphabetical order. Every new sample requires a row in this SVG, regardless of whether the compatibility pattern is unique. Mark each infrastructure cell as compatible (green check) or not compatible (red cross) based on the sample's supported infrastructures.
 7. Keep the canonical sample display name consistent across README tables, the website, the slide deck, and compatibility artifacts.
 
 ## Approach

.github/copilot-instructions.md

@@ -159,7 +159,7 @@ Whenever a new sample is added:
 - Update the root `README.md` sample table in alphabetical order.
 - Update `docs/index.html`, including the matching sample card and JSON-LD `ItemList` entry.
 - Update `assets/APIM-Samples-Slide-Deck.html` when the sample catalog, counts, or descriptions are surfaced in the deck.
-- Update `tests/Test-Matrix.md` and any compatibility diagrams or related assets that represent supported infrastructures.
+- Update `tests/Test-Matrix.md` and `assets/diagrams/Infrastructure-Sample-Compatibility.svg` (add a new row for the sample in alphabetical order, marking each infrastructure as compatible or not).
 - Keep the canonical sample display name identical across README tables, website cards, slide deck content, and compatibility diagrams.
 
 ### Jupyter Notebook (`create.ipynb`) Structure

.github/skills/sample-creator/SKILL.md

@@ -326,7 +326,7 @@ Update these files when a new sample is added:
 2. `docs/index.html` - Add the sample card and the matching JSON-LD `ItemList` entry.
 3. `assets/APIM-Samples-Slide-Deck.html` - Update sample inventory, counts, and sample descriptions where the deck surfaces them.
 4. `tests/Test-Matrix.md` - Add the sample row and mark unsupported infrastructures as `N/A` where appropriate.
-5. Compatibility diagrams and related assets - Update them whenever supported infrastructure changes must be reflected visually.
+5. `assets/diagrams/Infrastructure-Sample-Compatibility.svg` - Add a new row for the sample in alphabetical order. Every new sample needs a row here, regardless of whether the compatibility pattern is unique. Mark each infrastructure cell as compatible (green check) or not compatible (red cross).
 
 Keep the canonical display name identical across README tables, the website, the slide deck, and compatibility diagrams.
 

assets/diagrams/Infrastructure-Sample-Compatibility.svg

@@ -10,7 +10,7 @@ Implement dynamic, per-API CORS origin validation in Azure API Management using
 
 1. Understand why the built-in APIM `<cors>` policy cannot support fully dynamic origin validation and how to replace it with custom policy fragments.
 1. Build a reusable policy fragment that evaluates the `Origin` header against a per-API allowed-origins mapping, handling both OPTIONS preflight and actual request CORS headers.
-1. Compare three mapping strategies side-by-side: **hard-coded** (Phase 1), **Named Values** (Phase 2), and **cache-backed** (Phase 3), understanding the trade-offs of each.
+1. Compare four mapping strategies side-by-side: **native `<cors>` policy** (Baseline), **hard-coded** (Phase 1), **Named Values** (Phase 2), and **cache-backed** (Phase 3), understanding the trade-offs of each.
 1. Use an admin API (`/admin/load-cache`) to populate the APIM internal cache at runtime, demonstrating the `/admin/` convention for operational endpoints.
 1. Verify CORS behaviour with automated tests covering allowed origins, disallowed origins, missing `Origin` headers, and fail-closed cache behaviour.
 
@@ -39,7 +39,7 @@ This lab deploys all phases **side-by-side** so you can inspect and compare them
 > [!IMPORTANT]
 > **Production security:** The admin API in this sample is protected by a subscription key only. Subscription keys are shared secrets and are not a substitute for identity-based authentication. In production, you should add `validate-azure-ad-token` or `validate-jwt` to the admin API's inbound policy. See the [authX](../authX/) and [authX-pro](../authX-pro/) samples for implementation patterns. The policy XML includes a commented example of where to place the validation.
 
-- **Three APIM policy fragments** demonstrating different origin-mapping strategies:
+- **Three APIM policy fragments** (one per dynamic phase) demonstrating progressively more flexible origin-mapping strategies:
   - `DynamicCorsHardcoded` - origins embedded in a C# `switch` expression.
   - `DynamicCorsNamedValues` - origins read from an APIM Named Value as JSON.
   - `DynamicCorsCached` - origins read from the APIM internal cache. Returns `503` if the cache is not initialized (fail-closed).