# TASK 2.2: Propagate custom headers through Brink connection resolution and facade transport

## Summary

Attach persisted custom headers to outbound Brink facade requests.

This task completes the runtime value of the slice by taking the newly stored credential metadata and sending it on every relevant downstream request.

## Dependencies

- [TASK 2.1](./TASK2.1.md)

## Files to Modify

### Runtime transport

- `backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/Clients/BrinkAuthHeaderScopeFactory.cs`

### Supporting models or callers only if needed

- `backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/Clients/BrinkTransportRequest.cs`
- `backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/Clients/BrinkSoapExecutor.cs`
- `backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/BrinkRawClient.cs`
- `backend/integrations/Kds.Ai.Integrations.BrinkPos/Services/Facade/BrinkPosFacade.cs`

## Required Changes

### Header emission rule

Whenever a `BrinkConnectionDefinition` contains custom headers, the request-construction path should add them to the outgoing `HttpRequestMessage`.

That is in addition to:

- `SOAPAction`,
- current XML content headers,
- current `AccessToken` and `LocationToken` handling when `UseHeaderAuthentication` is enabled.

### Conflict rule

Document and implement what happens if a configured custom header collides with an existing framework-managed header such as:

- `AccessToken`,
- `LocationToken`,
- `SOAPAction`,
- `Content-Type`.

Recommended rule for this slice:

- framework-managed headers win,
- custom headers with reserved names are rejected during validation rather than silently overriding transport behavior.

### Logging rule

Do not log raw custom header values.

If request diagnostics mention custom headers at all, they should mention only names or counts, not secret values.

## Acceptance Criteria

- [ ] Every Brink facade request includes configured custom headers
- [ ] Existing auth-header behavior remains unchanged
- [ ] Reserved-header collisions are handled explicitly and safely
- [ ] No logging path exposes secret custom header values

## Notes

- Prefer adding the headers in one place, ideally the existing request factory, rather than distributing the behavior across multiple clients.
- Keep the runtime behavior deterministic across `Settings`, `Settings2`, `Sales2`, and `Kitchen` clients because they all share the same transport path.