Fix blocking S3 calls, unawaited cache notifications and startup provider

[KrzysztofPajak]

Type: bugfix

Issue

No issues were open for these; they came out of an audit of async and startup code. Three
independent defects, one commit each (plus a follow-up correcting one of them — see below).

1. AmazonPictureService.SaveThumb blocked three times on S3 I/O.
CheckBucketExists().Wait(), PutObjectAsync(...).Wait() and MakeObjectPublicAsync(...).Wait(),
all from the thread serving the request. Thumbnail generation runs on catalogue and product pages,
so on an S3-backed installation these tie up thread pool threads for the length of a round trip.
This is the case .ai/constraints.md prohibits — blocking in service code, not in a startup path.

2. MemoryCacheBase mishandled cache invalidation in two ways.

RemoveAsync and RemoveByPrefix called _mediator.Publish without awaiting it and returned
Task.CompletedTask. A failing handler surfaced as an unobserved task exception on the finalizer
thread; a slow one raced the caller, so an invalidation could still be in flight when the next read
hit the cache. These were the only two unawaited Publish calls in the solution.

Clear() disposed _resetCacheToken. A writer reads the token source, and MemoryCache then
registers an eviction callback on it while storing the entry — that registration throws
ObjectDisposedException on a disposed source.

Reproduced with a stress test: Clear running against concurrent SetAsync throws
ObjectDisposedException within roughly 120ms.

3. StartupBase.ConfigureServices built a throwaway service provider.
services.BuildServiceProvider() (ASP0000) purely to resolve IWebHostEnvironment — a second,
never-disposed container with its own singleton graph. The same method also instantiated every
IStartupApplication twice, once per configuration pass. Separately,
Grand.Module.Migration.Startup.StartupApplication resolved the scoped IMigrationProcess from the
root provider.

Solution

• SaveThumb is now async Task and awaits the three S3 calls. The base
  PictureService.SaveThumb already returns Task and every caller awaits it, so nothing else
  changes.
• RemoveAsync and RemoveByPrefix await the notification.
• Clear() cancels the token but no longer disposes it. The source is left to the garbage
  collector: Cancel releases the registrations, and it has no timer and no WaitHandle, so
  nothing needs releasing eagerly. Against develop this is a single removed line.
• ConfigureServices takes IWebHostEnvironment; all four hosts already have builder.Environment.
  Startup types are instantiated once and the list filtered per pass.
• The migration startup runs in its own scope. Its feature flag check still blocks, because
  Configure is synchronous, but GetAwaiter().GetResult() rethrows the original exception instead
  of wrapping it in an AggregateException.
• Three regression tests in Grand.Infrastructure.Tests.

A correction worth reading before reviewing commit by commit. The first attempt at the Clear()
race swapped the token with Interlocked.Exchange before cancelling and disposing, and the commit
message claimed that closed the window. It does not: a thread that read the field before the swap
still holds the source being disposed, so the stress test throws on that version exactly as it does
on develop. The follow-up commit removes the Dispose call, which is the actual fix, and drops
the Exchange as well — with Dispose gone it only guarded against two concurrent Clear calls
orphaning a token, which is a different and much milder problem, out of scope here.

Deliberately left alone, with reasons:

• MemoryCacheBase.Get<T> uses semaphore.Wait(). That blocks on a semaphore, not on a Task, and
  the method is a synchronous ICacheBase member — removing it means changing the interface.
• MigrationProductRating uses GetAwaiter().GetResult() and IStartupApplication.Configure
  blocks. Both are startup paths with synchronous contracts, which .ai/constraints.md explicitly
  does not treat as precedent.
• AzurePictureService.SaveThumb calls synchronous Azure SDK methods. That is a different problem
  from blocking on a Task and would widen this change.

Breaking changes

One. StartupBase.ConfigureServices gains a third parameter:

ConfigureServices(IServiceCollection services, IConfiguration configuration)
ConfigureServices(IServiceCollection services, IConfiguration configuration, IWebHostEnvironment hostingEnvironment)

All four in-repo hosts are updated. A custom host with its own Program.cs must pass
builder.Environment. It is a compile error, not a silent change. An overload was considered, but
keeping the old one means keeping the BuildServiceProvider call it exists to remove.

ICacheBase is unchanged — RemoveAsync and RemoveByPrefix already returned Task, and
RedisMessageCacheManager overrides both with matching signatures.

Testing

1. dotnet build ./GrandNode.sln — succeeds.
2. dotnet test ./src/Tests/Grand.Infrastructure.Tests/Grand.Infrastructure.Tests.csproj — 87/87 pass.
3. dotnet test ./src/Tests/Grand.Modules.Tests/Grand.Modules.Tests.csproj — 18/18 pass.
4. dotnet test ./src/Tests/Grand.Business.Storage.Tests/Grand.Business.Storage.Tests.csproj — 51 pass, 2 pre-existing skips.
5. To confirm the notification tests guard the defect, temporarily restore the fire-and-forget body
   of MemoryCacheBase.RemoveAsync and re-run step 2. RemoveAsync_AwaitsTheNotification fails
   while RemoveByPrefix_AwaitsTheNotification still passes. Revert.
6. To confirm the race test guards the defect, temporarily add _resetCacheToken.Dispose(); back
   into Clear() and re-run step 2. Clear_WhileEntriesAreBeingWritten_DoesNotThrow fails with
   ObjectDisposedException: The CancellationTokenSource has been disposed. Revert.
   The test only asserts on an exception the race actually raised, so it cannot fail spuriously — it
   can only miss.
7. Start each of the four hosts and confirm they boot and serve a page — this change touches every
   Program.cs and the shared composition root.
8. On an installation upgrading from an older database version, confirm migrations still run at
   startup; the migration process now executes inside its own DI scope.
9. S3 path, if you have a bucket configured: set the Amazon storage provider, upload a product
   picture and load the product page so a thumbnail is generated. It should be created and served
   as before.

Steps 7 to 9 have not been run here — they need running hosts, an upgradable database and an S3
bucket.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.