api: accept and ignore a per-request seed instead of rejecting it

[monotophic]

Authored by Claude Fable 5.1 in Claude Code, analysis in partnership with @monotophic

/v1/completions and /v1/chat/completions answer a request carrying seed with a 400 today. This
accepts the field and ignores it. The server puts no per-request seed on the wire, so the value has
no effect at any temperature, and docs/api.md says so rather than implying a determinism this build
does not have.

What changes. generation_options no longer raises on seed; nothing else in it moves. One
consequence: a request carrying seed together with an invalid response_format, max_tokens,
temperature, top_p or cache_slot now gets that field's 400, where the seed refusal used to
pre-empt those five. docs/api.md gains a short seed section and a pointer to it. In
c/tests/golden_fixture_capture.py the err_seed case becomes seed_accepted, at temperature 0; a
capture diff across this change prints err_seed.json: MISSING on one side and
seed_accepted.json: MISSING on one side and exits 1, and the other nine cases are byte-identical.

What does not change. A request without seed writes the same SUBMIT frame and gets the same
response as on dev; a test pins the frame for a request using only model, prompt, max_tokens
and temperature. /v1/messages drops seed in its request translation on dev and still does.
No engine source, no Makefile, no flag. One commit, four files.

Tests (c/tests/test_openai_server.py, run from c/): SeedWireFrameTest compares the whole
frame list for a seeded and an unseeded request on both endpoints, and SeedOptionTest checks the
option parser; both fail on dev. BaseWireContractTest pins the base frame literally and passes on
dev by design. test_openai_server.py and test_anthropic_messages.py: 229 green.

Limits. The value is not validated: a string or float seed is accepted and ignored like an
integer. An integer of thousands of digits in any field is a 500 on dev as well, at JSON parsing;
not touched here.

Context. This is split out of #1353, which is being reduced to its logprobs/echo work. The two
are independent — neither reads nor writes what the other changes — but both touch docs/api.md and
the header comment of the capture script, so whichever lands second needs a small prose rebase there.
A few further pieces of this work are proposed separately, each with its own evidence.