feat: report an unproved schedule as Feasible rather than Optimal

[andig]

The API documents Optimal as "Problem solved to optimality" and returns it for solves that were never proved.

pulp sets LpStatusOptimal whenever CBC came back with any feasible solution, including one it stopped on at the time limit. So a schedule truncated by OPTIMIZER_TIME_LIMIT reaches callers labelled as the proved optimum. Measured on one captured slow request, the same model at two budgets:

time limit	reported status	objective value
2 s	Optimal	-682,466,848
30 s	Optimal	59,714,881

Same model, same label, answers nowhere near each other. Around one percent of production requests hit the limit, so that is roughly one percent of responses currently overclaiming.

What this does

pulp does carry the distinction, in sol_status, and this folds it into the status field the response already has rather than adding a second field beside it. Callers branch on that field today, and the bug is that one of its values claims more than it can back:

status = pulp.LpStatus[self.problem.status]
if status == 'Optimal' and self.problem.sol_status != pulp.LpSolutionOptimal:
    status = 'Feasible'

Feasible is a usable answer, not an error. The response carries the same complete schedule an Optimal one does — same batteries, same grid series, same objective value — so the result payload is built for both and only the label differs.

This is a contract change

Clients that treat anything other than Optimal as a failure will start discarding roughly a percent of the schedules they use today, falling back to whatever plan they held. Nothing in this repo branches on the value, but the downstream consumer does, so the evcc side wants updating before this ships. If that ordering is awkward, the alternative is a separate boolean field and leaving status alone — say the word and I will switch it, though it leaves the documented meaning of Optimal wrong.

client/client.gen.go is regenerated from openapi.yaml with make build; the new value lands in the OptimizationResultStatus enum, so Go consumers get a compile-time constant rather than a bare string.

On the test

It simulates the truncation instead of provoking it with a small time limit, because CBC's -sec is not a wall clock on the request — it is only tested between branch and bound nodes, so a model that finishes in presolve or the root relaxation ignores it entirely. Every stored case still proves itself at a limit of 0.01 s, and 020-weird-charging-at-night takes 0.98 s regardless:

020-weird-charging-at-night   limit=0.01  -> Optimal in 0.98s
021-min-pv-use-case           limit=0.01  -> Optimal in 0.21s
009-discharge-before-import   limit=0.01  -> Optimal in 0.10s

So the test patches the solve to return what CBC returns on a real timeout, and asserts both the label and that the full payload survives it. Both gotchas are now recorded in AGENTS.md, since reading problem.status as "did it finish" is an easy trap to fall into twice.

Independent of #115 and #123 — the API tells this same story on main today.