Story: Hotfix: scheduler accepts six-field cron expressions

A job or report schedule written with six fields is refused with a message that names the field count, instead of being stored and run on a shifted schedule. ores.scheduler.api.tests passes again.

Main's vcpkg bump (978e1e098d) moved the croncpp port from 2023-03-30 to 2026-08-12. The new default traits accept an optional seventh field, the year. cron_expression::from_string prepends a seconds field and relied on croncpp to reject anything but five fields, so a six-field input now passes, read as minute, hour, day, month, weekday and year.

• cron_expression::from_string refuses any expression that does not have exactly five fields, and its error names the count it found.
• A test pins next_occurrence for an expression that restricts both day fields, so a later croncpp change to that rule fails a test.
• ores.scheduler.api.tests passes, with the new croncpp.

• Keep the new croncpp and check the field count in ORE Studio. Pinning the old port would leave the parser depending on what a library version happens to refuse.
• Keep croncpp's new day rule. With both day fields restricted, the old version fired only on a day matching both; the new default fires on a day matching either, which is POSIX cron, and the header documents the format as standard Unix cron. No seeded or hard-coded schedule restricts both day fields, so no existing schedule changes its times.

Done. The parser refuses any count but five fields.