The feature flags module invents a contract where OpenFeature already is one

`BarakoCMS.FeatureFlags` serves flags from its own shape: `GET /api/feature-flags` for evaluation, `/api/feature-flags/admin` and `/admin/{key}/toggle` for management. Every consumer of those flags writes a client against a contract that exists only here.

OpenFeature is a CNCF specification with an Apache-2.0 licence and SDKs for the languages a barakoCMS front end is likely written in. Speaking it turns our module from an API someone integrates with into a provider someone plugs in.

## Why it matters

Two directions, and the second is the interesting one.

Outward: a front end that already uses the OpenFeature SDK can read barakoCMS flags with no bespoke client. That is one fewer thing to write and one fewer thing in #187's drift problem.

Inward: a client whose flags live in Unleash (Apache-2.0) or Flagsmith (BSD-3) today does not have to migrate to adopt barakoCMS. They keep their flag store, and our module becomes one provider among theirs. That removes an adoption blocker we currently create by asking them to move.

Neither requires running anything extra. This is a contract, not a container.

## What to change

- Serve the evaluation endpoint in the OpenFeature evaluation shape, alongside the current one for as long as 4.x supports it — the current route is public API and section 6 of CLAUDE.md applies.
- Publish a small provider so an OpenFeature SDK can point at an instance.
- Say in the README which parts of the spec are covered. Targeting rules and context-based evaluation are a large surface; covering boolean and string flags honestly beats claiming the spec and half-implementing it.

## What has to stay true

- Flags stay per tenant. Evaluation context arriving from a client must not become a way to read another tenant's flags.
- Evaluation stays cheap and anonymous where it is today, and the response stays cacheable.
- The admin surface stays ours. OpenFeature is an evaluation standard; management is out of its scope and does not need to change.
- Nothing in core learns about OpenFeature. This lives in the module.

## Done when

- An OpenFeature SDK reads flags from an instance with no barakoCMS-specific code.
- The existing endpoint still answers, with an obsolescence note pointing at the new one.
- The README states the covered subset of the specification.

Found while surveying adjacent open source for integration candidates.

Start by tracing the existing /api/feature-flags evaluation route and the module boundaries, then read section 6 of CLAUDE.md and the README. Compare the current response with the OpenFeature evaluation shape and define the limited boolean and string subset, while preserving tenant isolation, caching, and the existing admin routes. Done means an OpenFeature SDK can evaluate flags without barakoCMS-specific client code, the current endpoint remains available with an obsolescence note, and the README documents the covered subset.

Written by the indexing model from the issue text.