Document how a bundle acquires acquisitionCapabilities and holderBoundBatchMaxSize

Found while verifying adopter-facing configuration documentation against the v0.21.0 release.

## Gap

`products/evidence/reference/request-adapter/deployment-projects/CONFIG.md` documents the bundle-side `acquisitionCapabilities` (at most `search-then-fetch-set` and `source-batch`) and `holderBoundBatchMaxSize` (1 through 16, omission means 1), including the two-sided gate where the bundle opts in and the runtime separately enables.

But no documented authoring path can set the bundle half. `evidencectl build` reads only `governance.yaml`, `runtime.yaml`, and `public-keys/` from the target, and the closed `governance.yaml` grammar does not carry either key; the authoring form has no acquisition concept. So at v0.21.0 every compiled candidate carries the defaults (no gated kind, batch ceiling 1), and a bundle with non-default values can only exist if it is maintained directly as a deployment project, bypassing `evidencectl build` entirely.

CONFIG.md documents the keys as if an adopter could reach them, without saying that the build pipeline cannot produce them.

## Suggested fix

Pick one:

1. Document explicitly that as of the current release these two keys are only settable in directly maintained deployment projects, and that `evidencectl build` output always carries the defaults.
2. If gated acquisition and batch release are meant to be reachable through the supported build path, add a governed input for them (target governance or a build flag) and document it.

Start with products/evidence/reference/request-adapter/deployment-projects/CONFIG.md, then inspect evidencectl build and the documented governance.yaml, runtime.yaml, and public-keys/ inputs. Trace how acquisitionCapabilities and holderBoundBatchMaxSize reach compiled candidates; done means the documentation accurately explains whether supported builds can produce non-default values and what authoring path applies.

Written by the indexing model from the issue text.