docs(configuration): add Configuration section to reference.md (#351)

[oaksprout]

You set the work. #351: the Configuration building block (subscribeConfiguration et al.) shipped long ago, but documentation/reference.md has no Configuration section.

It's done. A ## Configuration section documenting get, subscribe (plain, with-keys, with-metadata), and unsubscription via stream.stop() — mirroring the structure of the one section that has real content (Service Invocation). Every snippet is based on the working examples/configuration/ code and was compile-checked against the real exports (tsc --noEmit, strict, zero errors). One caveat surfaced and documented: the Configuration API is gRPC-only — the HTTP client throws HTTPNotSupportedError for all four methods, which is broader than the issue implied.

Here's the evidence.

• Fresh clone at f7800662, patch applied, npm install && npm run build, then the network was disconnected.
• Unit suite in a clean node:22-bookworm container: all 10 suite groups pass.
• Prettier introduces zero new violations (same 56 pre-existing non-conforming files with or without this change); eslint untouched by a docs-only diff.

Audit trail — an independently checkable record that these checks ran, in this order, before this PR existed

Base commit	f78006628ea259d16173a78184b929292f1d612f
Container	node:22-bookworm@sha256:5647be70… (linux/arm64), network off during tests
The patch, content-addressed	record
The verification result, signed by a second key	record
Timestamped sequence	work assigned → work delivered → checks passed

What this proves: the checks ran, in that order, on exactly this patch, before this PR was opened — none of it can be backdated or swapped afterwards. What it doesn't prove: that the docs are right in every nuance. The two signing keys are distinct but run by the same project, and the record lives on a test network. Correctness is your judgement, which is the point.

Written by an AI agent; reviewed and sent by a human who answers the review, signed off per the DCO. We're testing whether work checked this way is useful to maintainers — blunt feedback welcome, including "don't".

---

Everything below is written by Claude

Closes #351.

One file changed: documentation/reference.md, +30 lines. Structure mirrors Service Invocation (one-line description + link to the matching Dapr API doc, then ### subsections with short TypeScript snippets); the other section headers (State Management, Pub/Sub, Bindings, Actors, Secrets) are empty stubs since 2021 and were left untouched.

Notes for the reviewer

• The section is intentionally skeletal to match the file's actual current style — if you'd like fuller coverage (error handling, a link to examples/configuration/, the Redis metadata caveat from the e2e comments), happy to extend.
• documentation/examples.md also lacks a Configuration entry — a second, separate gap left alone here; can follow up.