Implement attribution with an agent

You are adding Hicap AI Gateway support and base usage attribution to this codebase.

Context — how Hicap attribution works:
- Requests go through an OpenAI-compatible endpoint at https://api.hicap.ai/v1.
  Authentication is the API key sent as the `api-key` HTTP header. The key comes
  from the HICAP_API_KEY environment variable — never hard-code it.
- "Structural" attribution (which Organization/Application/Key a request belongs
  to) rolls up automatically from the key, so I do NOT need to send anything for
  that at call time.
- "Descriptive" attribution is what I DO send per request: a set of tags. Tags are
  sent in a single HTTP header called `x-hicap-tags` (plural). Its value is ONE
  JSON object mapping dimension keys to string values, e.g.
  {"feature": "checkout", "channel": "web", "env": "production"}.
  Send exactly one such header per request. Do not repeat the header or use
  comma-separated pairs.

Do the following:
1. Find where this codebase calls language models today (search for the OpenAI SDK,
   HTTP calls to a model provider, or an existing AI client wrapper). If there is
   no such call yet, create a small client module in the idiomatic place for this
   project.
2. Point the client at Hicap: base URL https://api.hicap.ai/v1, and send the key as
   the `api-key` header, read from the HICAP_API_KEY environment variable. Keep any
   existing behavior working. Add HICAP_API_KEY to the project's example env file
   (e.g. .env.example) with a placeholder value and a short comment.
3. Add a single helper that builds the `x-hicap-tags` header from a plain map and
   attaches it to a request. It must JSON-encode the map and set exactly one header.
   Route model calls through this helper so tagging is consistent.
4. Establish base attribution. Set these service-level dimensions once, in one place,
   so every request carries them:
     - env      (e.g. "production", "staging", "development" — derive from config)
     - system   (a stable short name for this service/app)
   Then tag per call with:
     - feature  (what the specific call is for — pass it in at each call site)
   Leave the map open so more dimensions can be added later. Use lowercase
   snake_case dimension keys and short, stable string values.
5. Update the 2–3 highest-traffic call sites to pass a real `feature` value so the
   result is demonstrable, and leave a clear pattern for the rest.
6. Add or update a short section in the project README explaining how attribution is
   wired: the env var, the tags helper, and how to add a dimension.

Constraints:
- Keep the diff surgical and idiomatic for this codebase. Match existing style,
  config, and dependency-management conventions.
- Do not invent dimensions beyond env, system, and feature unless the codebase
  clearly needs one. It is better to leave the map extensible than to over-tag.
- Do not log, print, or commit the API key. Do not add real secrets to any file.

When you're done, show me: the client change, the tags helper, one tagged call site,
and the README section. Then summarize what remains for me to roll out to the rest of
the call sites.