Register `MemoryMappedFileAccessor` only if shared memory transfer is enabled

The shared memory accessor `MemoryMappedFileAccessor` (for both unix and windows) is currently always registered even when the worker does not have the capability for it. This is inefficient. We should consider changing the way this works so that we first validate if shared memory transfer is enabled as per the following conditions:

https://github.com/Azure/azure-functions-host/blob/3a5d1010433d7fbee142b3a13fb43d20874c9b27/src/WebJobs.Script.Grpc/Channel/GrpcWorkerChannel.cs#L1575-L1582

#### Other (non blocking)

A noisy side effect of this is the following Core Tools [issue](https://github.com/Azure/azure-functions-core-tools/issues/2600) where user's see this error even when shared memory is not used:

```log
[2025-08-05T14:22:00.137Z] Cannot create directory for shared memory usage: /dev/shm/AzureFunctions
[2025-08-05T14:22:00.137Z] System.Private.CoreLib: Access to the path '/dev/shm' is denied. Operation not permitted.
```

https://github.com/Azure/azure-functions-host/blob/3a5d1010433d7fbee142b3a13fb43d20874c9b27/src/WebJobs.Script/Workers/SharedMemoryDataTransfer/MemoryMappedFileAccessorUnix.cs#L199

Start in GrpcWorkerChannel.cs around lines 1575-1582 and trace where MemoryMappedFileAccessor is registered for Unix and Windows. Read MemoryMappedFileAccessorUnix.cs around line 199 to understand the reported side effect. Done means the accessor is registered only when the referenced shared-memory capability conditions are satisfied, avoiding the directory error when transfer is unavailable.

Written by the indexing model from the issue text.