Should not capture context/scheduler

**Describe the bug**

Internal `await`s in the library capture the synchronization context. This can cause deadlocks.

**To Reproduce**

From UI thread/context:
1 start operation
2. wait for it synchronously,
3. get the result when done

```c#
Task getSecretTask = cache.GetSecretString("foo");`
LoadingAnimation.Show();
getSecretTask.Wait()
LoadingAnimation.Hide();
TextBox.Value = "Got secret: " + getSecretTask.Result;
```

**Expected behavior**

`getSecretTask.Wait()` doesn't deadlock.

**Additional context**

The internal await in the library posts the continuation on the current sync context, which is the UI thread. UI thread is busy, waiting for the library. This deadlocks.

The example is intentionally simplified one and tries to mimic: https://devblogs.microsoft.com/dotnet/configureawait-faq/

My actual use case where I ran into this is a lot more complicated but the basic mechanism is the same; an internal scheduler from a component ends up getting captured in the caching library. When the component is destroyed, the leaked scheduler becomes stale which causes cache lib to hang. This deadlocks any other components using the caching lib.

PR with a test incoming soon.

Start with the GetSecretString call and the synchronous Wait/Result reproduction described in the issue, then trace the library's internal awaits and continuation scheduling. Confirm the deadlock from a UI or synchronization-context thread and verify that the operation completes without capturing the caller's context; the issue mentions a test PR is incoming but names no existing files or tests.

Written by the indexing model from the issue text.