Fix triggerBrandDetection batch ID contract with DRS

## Problem

`DrsClient.triggerBrandDetection(siteId, options)` does not implement the DRS brand-presence reanalysis contract.

The public client API documents `options.batchId` as optional and forwards the options object unchanged. DRS requires the wire field `batch_id`, so both supported-looking calls are invalid:

- Calling without options sends an empty body and receives `400 {"error":"batch_id is required"}`.
- Calling with `{ batchId: ... }` sends camelCase while DRS reads `batch_id`.

The package unit test currently asserts the incorrect camelCase request body, allowing the mismatch to persist.

## Required behavior

Keep the JavaScript API camelCase, but make a non-empty `batchId` mandatory and serialize the request according to the DRS OpenAPI contract:

```js
await client.triggerBrandDetection(siteId, {
batchId,
priority: 'HIGH',
});
```

Wire body:

```json
{
"batch_id": "",
"priority": "HIGH"
}
```

## Acceptance criteria

- `triggerBrandDetection` rejects a missing or blank `siteId`.
- `triggerBrandDetection` rejects a missing or blank `batchId` before making an HTTP request.
- `batchId` is serialized as `batch_id`.
- Only DRS-supported priority values are documented and typed.
- `index.d.ts`, README examples, and unit tests describe the same contract.
- Tests assert the exact snake_case HTTP request body and the no-batch rejection.
- The release notes identify the previously non-functional no-options call so consumers update their callers.

## Evidence

DRS documents `batch_id` as required for `POST /sites/{siteId}/brand-detection`. The endpoint loads the corresponding brand-presence tracking file and validates that the batch belongs to the requested site; it cannot perform reanalysis without a real collection batch.

A production `llmo-customer-analysis` run on 2026-09-01 reached this endpoint with an empty body and received the expected `400` response after prompt generation had otherwise completed.