Feature request: support extra_headers in config.toml

[lionhylra]

Problem

Some litellm providers and local proxies require custom HTTP headers on every
request — for example:

• Anthropic extended features: anthropic-beta: interleaved-thinking-2025-05-14
• LiteLLM proxy authentication: x-litellm-api-key: <token>
• Observability / tracing: x-trace-id: my-service

There is currently no way to pass these headers through OpenChronicle's config.
Users who need them must fork the code or intercept at the network layer.

Proposal

Add an optional extra_headers table to any [models.*] section. Headers are
forwarded verbatim to every litellm.completion() call for that stage, and
inherited from [models.default] like all other model fields.

[models.default]
model = "claude-opus-4-5"
api_key_env = "ANTHROPIC_API_KEY"

[models.default.extra_headers]
anthropic-beta = "interleaved-thinking-2025-05-14"
x-trace-id     = "openchronicle"

[models.classifier]
model = "claude-opus-4-5"
# inherits extra_headers from default; override per-stage if needed

Behaviour

• extra_headers defaults to {} — no change for existing configs.
• Stage sections inherit the default's headers unless they define their own
  extra_headers table, which fully replaces (not merges) the default for
  that stage.
• Values must be strings; non-string TOML values (e.g. integers) are rejected
  at the litellm call site.

Implementation notes

Changes required in two files:

1. src/openchronicle/config.py — add extra_headers: dict[str, str]
   field to ModelConfig; copy the dict in _build_models when inheriting
   from default so each stage owns an independent dict.
2. src/openchronicle/writer/llm.py — pass extra_headers to
   litellm.completion() in both call_llm and ping_stage (a shallow copy
   prevents litellm from mutating config state).

PR

Implementation + tests available at
main...lionhylra:OpenChronicle:support-extra-headers

@lionhylra

看到有人质疑这个项目的 Star 后，预计维护者可能会用一些常见的说辞来回应。提前做个分析：

Q: "可能是某篇文章带来的自然增长"
A: 自然增长的 Stargazer 应该是有真实资料和活动记录的账号。而实际情况是：没头像没仓库没 follower。这不是自然增长的特征。

Q: "可能是竞争对手恶意刷的"
A: 这个可能性存在，但概率很低。如果是这样，维护者应该立刻联系 GitHub 配合调查并公开说明。沉默只会让人更加怀疑。

Q: "Star 数只是一个数字，不代表什么"
A: 如果 Star 数不重要，为什么要去刷？这个说法本身就自相矛盾。

Q: "我不知情，是别人帮我刷的"
A: 即便如此，你也有责任在发现后及时清理并说明。知情不报等于默许。

数据摆在这里：抽查 76 个账号 26 个无仓库。不管什么理由，该处理的还是要处理：

• 联系 GitHub 官方配合排查
• 坦诚面对问题
• 清理掉明显的假账号
• 发布一份正式声明
• 把钱花在写测试上

真金不怕火炼，假星经不起推敲。
违规核定无误，举报上报官方，违规人气清空，项目访问关闭。