Write ADR for method parameter guidelines

## Description
For publicly available methods, it is often convenient to pass a custom object containing the required parameters, instead of a long list of individual parameters.

This allows us to more easily avoid breaking changes to the contract, as well as allowing the callers to potentially write more compact and easily understood code.

## Example
```csharp
// Before
public Task Method(string org, string app, Guid id, CancellationToken cancellationToken);

// After
public Task Method(Arguments args, CancellationToken cancellationToken);

public sealed record Arguments(string Org, string App, Guid Id);
```

## Tasks
Write an ADR containing the guidelines for the usage described above. The document should cover the following topics:
- _When_ is it appropriate to use custom parameter-objects vs. a list of individual parameters?
- Is the decision here linked to the number of arguments, or should we always prefer one over the other?
- _Naming_ for custom types. This is probably at least partially context specific, but the guidelines should cover some common scenarios. Examples of naming:
- [Method]Request
- [Method]Context
- [Method]Parameters

Start by locating existing ADRs and their structure in the repository, then review how public C# APIs currently represent method parameters. Draft an ADR that defines when to use parameter objects versus individual arguments and gives context-appropriate naming guidance for types such as [Method]Request, [Method]Context, and [Method]Parameters.

Written by the indexing model from the issue text.