[mgravell]

• Reinstates automatic enlistment for the hosted providers, which 3.3.0 shipped with deliberately withheld so
  that maintenance notifications went out purely opt-in.
• removes the SER010 experimental annotation against smart-client-handoffs APIs

Nothing here is new behaviour: #3191 built and reviewed this, and the overrides were commented out rather than
deleted precisely so that what came back would be exactly what was reviewed. This is that, so it should read as
a revert of the withholding rather than as a change.

What turns on

You connect to	Recognized as	Notifications
something.cloud.redislabs.com, .cloud.redis.io, .redislabs.com	Redis Cloud	on (Auto)
something.redis.azure.net, .redisenterprise.cache.azure.net	Azure Managed Redis	on (Auto)
defaults=enterprise, defaults=rediscloud, defaults=amr	named explicitly	on (Auto)
anything else	nothing	off

Auto, not Enabled, throughout: a deployment that cannot deliver has to keep working, so the opt-in is
refused and the feature simply stays off. Enabled means required and rejects such a connection, which is a
choice a caller makes deliberately.

The library default stays Disabled. Only the three hosted providers enlist. OSS Redis, Valkey and Garnet
do not know the subcommand, and an unsolicited error reply on every connection would be a poor first
impression.

Why this is safe to turn on

The evidence from #3191, all against real deployments:

• Redis Enterprise and Redis Cloud: 26/26 fault-injector scenarios, MOVING handoffs acted on ~16s before the
  server closed the socket, endpoint retirement proven against a real node removal, and the destructive family
  (shard, node and proxy failure) run supervised.
• Azure Managed Redis, which is the pre-emptive case and therefore the one that needed checking: AMR does not
  emit these yet, so the opt-in is refused with ERR unknown subcommand 'MAINT_NOTIFICATIONS'. Measured on a
  live instance, the connection survives that in sync - PING, ECHO, PING all correct afterwards -
  which matters because the opt-in is pipelined with HELLO, AUTH and the CLIENT commands before any reply
  is read. A server that closed the connection, desynchronised the reply stream, or answered a hopeful +OK
  would have made this default harmful rather than merely inert. AzureManagedRedisOptInTests keeps that
  reproducible, and is written so that the day AMR ships support the same tests report accepted instead.

Changes

• The three provider overrides return in their original form.
• PublicAPI.Unshipped.txt regains the three [SER010]override entries; eng/public-api.py --check agrees the
  file is sorted.
• Docs follow the behaviour back: ServerMaintenanceEvent.md returns to "usually not" with the two-column
  now/will-be table collapsed and the temporary notice dropped, and Configuration.md and exp/SER010.md lose
  their "purely opt-in" paragraphs. The defaults= table row added while the feature was opt-in is kept, since
  it is useful either way.
• DefaultOptionsTests.MaintenanceNotificationDefaultPerProvider flips its first two rows to Auto, which is
  what it was written to do. The last two stay Disabled, and they are what stops the theory passing merely
  because every host returns the same answer.

MaintenanceOptInClientTests.DefaultIsOff needed no change: it connects to the in-process server on loopback,
which no provider recognizes, so Disabled is still right there.

One thing to decide before merging

main has since promoted geo-redundant failover out of preview, and maintenance notifications are suppressed
inside a multi-group connection - documented as "in development", because how a handoff and a cross-region
failover should agree about who is in charge is not yet settled. With auto-enlistment reinstated, a recognized
Redis Cloud hostname inside a ConnectGroupAsync group gets Auto and has it suppressed, with a warning
logged. That is the designed behaviour, but it becomes reachable without anyone configuring anything, where
before it needed an explicit maintNotifications.

Verification

dotnet build Build.csproj clean across every TFM. Full suite on two cores in Release with CI=true: 6470
passed, 0 failed, 161 skipped.