[FEATURE REQ] Language Analyze Documents: expose authoritative billable page equivalents in job results

### API Spec link

https://github.com/Azure/azure-rest-api-specs/tree/main/specification/cognitiveservices/data-plane/LanguageAnalyzeDocuments

### API Spec version

2026-05-01 and 2026-05-15-preview

### Please describe the feature.

## Summary

Please expose the authoritative metered usage for Azure AI Language **Document PII redaction** in the terminal response of the Analyze Documents long-running operation.

The service is priced and invoiced using pages, but the API response does not currently return the page quantity that Azure uses for billing. This prevents customers from reliably reconciling individual jobs with billed consumption.

## Affected operation

POST {endpoint}/language/analyze-documents/jobs
GET {operation-location}

Observed with API versions:

- `2026-05-01`
- `2026-05-15-preview`

The poll request used `showStats=true`.

## Current behavior

The completed job exposes statistics such as:

- `documentsCount`
- `validDocumentsCount`
- `erroneousDocumentsCount`
- `transactionsCount`

Per-document statistics expose values such as:

- `charactersCount`
- `transactionsCount`

The submit and poll response headers, the terminal response body, the per-document `result.json`, and the returned `entities[]` were checked. None exposed a page count or page anchor.

Neither `pageCount` nor another authoritative billable usage value is returned.

`transactionsCount` cannot safely be treated as a page count. In the reported test, a two-page PDF with `charactersCount: 2715` returned `transactionsCount: 3`. File metadata and locally calculated physical page counts also cannot prove the quantity that the Azure meter ultimately records.

## Problem this solves

Without an authoritative usage value in the response, customers cannot reliably:

- reconcile individual Document PII jobs with Azure invoices;
- implement accurate FinOps allocation and internal chargeback;
- forecast and enforce workload budgets;
- audit which documents caused a usage or cost increase;
- distinguish physical pages, processing transactions, and billed units;
- account for failed or partially processed documents.

Inferring cost from character counts, transaction counts, or local PDF metadata is inherently ambiguous. Comparable Azure services already expose a billing-related quantity—for example, Document Intelligence returns pages, Content Understanding returns usage, Translator returns `totalCharacterCharged`, and the Language synchronous path returns `csp-billing-usage`.

## Proposed API contract

Add an explicit, authoritative metering value to the terminal job result. For example:

{
"statistics": {
"documentsCount": 1,
"validDocumentsCount": 1,
"erroneousDocumentsCount": 0,
"transactionsCount": 3,
"billablePageEquivalents": 2.0
}
}

Where feasible, expose the same value per document:

{
"id": "document-1",
"statistics": {
"charactersCount": 2715,
"transactionsCount": 3,
"billablePageEquivalents": 2.0
}
}

The numeric values above are illustrative; the service must return the actual metered quantity, which cannot currently be derived from the response.

The exact property name may be `billablePages`, `billablePageEquivalents`, or another clearly documented name. The important requirement is that it represents the **exact quantity sent to Azure's billing meter**, rather than an estimate.

## Why a normalized billing unit is preferable to only `pageCount`

A physical page describes document structure, but does not necessarily describe metered processing. PDF pages can have unusual dimensions or be exceptionally information-dense. A normalized `billablePageEquivalents` value lets the service apply documented rules for dimensions, content density, supported limits, partial processing, or future changes without requiring customers to reverse-engineer the billing calculation.

The API can optionally expose physical `pageCount` as separate informational metadata, but that should not be confused with authoritative billed usage.

## Expected behavior / acceptance criteria

1. The terminal job response exposes the exact usage quantity recorded by the billing meter.
2. The value is available at job level and, where technically possible, per document.
3. The sum of per-document values reconciles with the job-level value.
4. Billing behavior for failed, skipped, or partially processed documents is clearly defined.
5. The property is documented as the authoritative value for invoice reconciliation.
6. Existing statistics remain unchanged for backward compatibility.
7. If the meter applies normalization or rounding, the returned value already includes it.
8. The value is stable and suitable for automated FinOps, chargeback, and audit workflows.

## Customer impact

Returning authoritative metered usage would give customers transparent, abuse-resistant cost accounting while allowing Azure to retain flexibility in how a billable page equivalent is calculated. It removes the need to infer charges from unrelated statistics and makes the service practical for workloads with strict financial governance and audit requirements.

Start in the LanguageAnalyzeDocuments API specification, focusing on POST /language/analyze-documents/jobs, the operation-location GET response, and the showStats=true terminal result. Review the existing job-level and per-document statistics, then define how authoritative billable usage would appear and reconcile, including failed or partial documents. Done means the contract clearly documents the returned metered quantity without changing existing statistics.

Written by the indexing model from the issue text.