Update rate-limiting-retry-after-preview4.md

Removing code snippet per review suggestion. It is not relevant to the ASP.NET Core rate limiting middleware scenario.

Author: wadepickett

aspnetcore/release-notes/aspnetcore-11/includes/rate-limiting-retry-after-preview4.md

@@ -4,25 +4,6 @@ The <xref:System.Threading.RateLimiting.FixedWindowRateLimiter> now reports a <x
 
 Previously, the `RetryAfter` metadata wasn't reliably set, which meant rejected responses either lacked the header or contained an unhelpful value. With this fix, any app that uses the rate-limiting middleware with a <xref:System.Threading.RateLimiting.FixedWindowRateLimiter> benefits from correct `Retry-After` headers automatically.
 
-The following example shows how a rate limiter lease exposes the `RetryAfter` metadata after a failed acquisition:
-
-```csharp
-using System.Threading.RateLimiting;
-
-var limiter = new FixedWindowRateLimiter(new()
-{
-    PermitLimit = 10,
-    Window = TimeSpan.FromSeconds(1),
-    QueueLimit = 0,
-});
-
-RateLimitLease lease = limiter.AttemptAcquire();
-if (!lease.IsAcquired && lease.TryGetMetadata(MetadataName.RetryAfter, out TimeSpan retry))
-{
-    Console.WriteLine($"Retry after {retry}.");
-}
-```
-
 Additional fixes in `System.Threading.RateLimiting` resolve an issue where <xref:System.Threading.RateLimiting.TokenBucketRateLimiter> mishandled partial token refills during zero-permit acquisition, and improve `System.Threading.RateLimiting.ChainedRateLimiter` to correctly forward idle-duration and replenishment behavior from its inner limiters.
 
 For more information, see [Rate limiting middleware in ASP.NET Core](/aspnet/core/performance/rate-limit).