Exception Thrown by CosmosDBInput Decorator When Item Not Found in CosmosDB

### Description

I am currently exploring the functionality of the CosmosDBInput decorator based on an [example provided in your documentation](https://github.com/Azure/azure-functions-dotnet-worker/blob/f3e546e7e0729e720debccbc817cec08b3872417/samples/Extensions/CosmosDB/CosmosInputBindingFunctions.cs#L111). I have successfully implemented a case where I retrieve an item from the database using an ID passed through Query Parameters, and it works as expected. However, in an error scenario where I provide an ID via Query Parameters that is not found in the database, the behavior is not as anticipated (in my opinion).

According to the provided example, I understand that the decorator should return a null object in case the element is not found, allowing me to handle this scenario programmatically. However, I noticed that the decorator deliberately throws an exception when it fails to retrieve the element. If this behavior is intended, it would be beneficial for the example to address the scenario where a element is not found.

While I acknowledge the importance of handling null objects defensively, I would like to understand the rationale behind throwing an exception in this particular case. It seems that allowing the decorator to return a null value could provide developers with more flexibility in error handling and tracing. The ability to choose between returning null or throwing an exception might cater to different use cases and preferences.

I have examined the decorator's code and observed that it intentionally [raises an exception](https://github.com/Azure/azure-functions-dotnet-worker/blob/f3e546e7e0729e720debccbc817cec08b3872417/extensions/Worker.Extensions.CosmosDB/src/CosmosDBConverter.cs#L115) when the element is not found (One of the expected behaviors). If this is the intended behavior, it would be beneficial for the example to address the scenario.

This is my source code:

```csharp
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace My.Function;

public class Bookmarks(ILogger logger)
{
[Function("Bookmarks")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
[CosmosDBInput(
databaseName: "func-io-learn-db",
containerName: "Bookmarks",
Connection = "CosmosDBConnection",
Id = "{Query.Id}",
PartitionKey = "{Query.Id}")] BookmarksItem bookmarks
)
{
logger.LogInformation("C# HTTP trigger function processed a request.");

if (bookmarks == null)
{
return new BadRequestObjectResult($"Not Found");
}

return new OkObjectResult($"Found Bookmarks, Url={bookmarks.Url}");
}
}

public class BookmarksItem
{
public string Id { get; set; }
public string Url { get; set; }
}
```

It is built with Net 8, Worker 1.21.0, Worker.Extensions.CosmosDB 4.6.0

### Steps to Reproduce:

- Create an Azure Cosmos Db NoSql with some entries (Id, value)
- Set up a Function App with an HTTP trigger in your local environment.
- Deploy Function App to Azure
- Set the "CosmosDBConnection" environment variable with the connection to Cosmos DB.
- Send an HTTP request to the Function App URL with the "Id" query parameter configured with a value that does not exist in the Cosmos DB.
- Observe that the request results in a 500 error instead of returning a 400 Bad request handled to my code in case of null value object, as expected based on the logic of the CosmosDBInput decorator.

Start with extensions/Worker.Extensions.CosmosDB/src/CosmosDBConverter.cs at line 115 and the linked sample Extensions/CosmosDB/CosmosInputBindingFunctions.cs at line 111; trace the not-found path and compare it with the documented binding behavior. Reproduce the missing-ID request described above, then verify that the chosen behavior and example handling are consistent.

Written by the indexing model from the issue text.