core: NewPeriodicTask.kwargs is written and read by nothing

NewPeriodicTask.kwargs and PeriodicTask.kwargs exist end to end — struct field, column, all three backend implementations — and nothing writes them or reads them.

Nothing writes it. The Python binding takes args and never receives a separate kwargs (crates/flexiq-python/src/py_queue/mod.rs), because the decorator folds args and kwargs into one payload before it crosses the boundary. The Rust shell (#916) writes kwargs: None.

Nothing reads it. Scheduler::check_periodic builds the fired job's payload from task.args alone (scheduler/maintenance.rs).

So a value written there would be stored faithfully and then ignored at fire time — which is the bad shape for a dead field: it looks usable.

What to decide

• Drop it, with a migration. Needs a check that no deployment has ever written it, and it costs a drop_column — see #812 for what that involves and what it does to the contract level.
• Use it: have check_periodic merge kwargs into the fired payload. That means deciding how a stored args envelope and a stored kwargs map combine into one call envelope, which no shell currently has an opinion about because none of them send both.
• Document it as reserved, if the column is wanted for a future shape and the cost of removing it is not worth paying.

Anything is better than the current state, where it reads as a supported field.

Found while building the Rust shell (#916).

Start with crates/flexiq-python/src/py_queue/mod.rs and scheduler/maintenance.rs to trace how kwargs is represented and whether it reaches fired jobs. Then review #812 for the migration and contract implications; done means choosing and implementing one disposition for the field with the corresponding migration, behavior, or documentation.