refactor: drop the unread backend field from Automation templates

[yihanzhu]

Summary

ScheduledTaskExecutionTemplate.backend is durable state nothing reads: the fire path builds the execution session without consulting it, and after #3249 session creation no longer accepts a backend from any caller. This drops the field from the template, stops copying header.backend in executionTemplateFromHeader — the writer that could still freeze a legacy 'fake' into a new record (#3211) — and stops emitting it from the protocol decoder. No migration, the same position #3226 and #3249 took for session headers.

Fixes #3306

Review focus

The execution decoder is a closed shape, so backend moves from the required key list to the optional one instead of disappearing: Automations frozen by older builds still carry it and must stay decodable. The key is tolerated on the way in — stored, create, and update — and never lands on the decoded value.

Removing the field from Host responses changes that closed wire shape. This branch is rebased onto main at epoch 33 and advances it to 34, so an epoch-33 Client receives the structured incompatibility handshake before a ScheduledTask command can be admitted rather than failing on its first Automation response.

Verification

• @maka/core: 576 pass
• @maka/runtime-host: 1046 pass
• Root build, typecheck, lint, and format pass
• Regressions cover legacy backend: 'fake' input in all three directions and a previous-epoch Client rejected before its ScheduledTask query

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code (Fable 5) — original implementation and tests; Codex — review analysis, rebase, compatibility epoch update, mixed-version handshake regression, and verification. Material commits carry a Generated-by trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — new canonical Automation records and decoded templates no longer carry backend; stored records that do remain readable, and mixed-version peers fail during the compatibility handshake

[yihanzhu]

The CI failure is in the unrelated Storage credential-store concurrency test:

serializes concurrent writes across slugs without clobbering

This PR does not modify Storage or the file-lock implementation, and the surrounding main runs are green. I do not have repository permission to rerun failed jobs. Could a maintainer please rerun the failed job?

If the same test fails again, I’m happy to help isolate it as a separate CI flake.

[Astro-Han]

Thanks for removing this unread state at its existing core and protocol boundaries. I reviewed exact head 9e29df41af4713989b4651d0858c3ba0a7fb001b. Keeping legacy backend keys readable while preventing them from entering new canonical records is the right first-principles direction, and this version has stronger compatibility coverage than the parallel #3337 implementation. I left one P2 wire-compatibility issue below.

AI-assisted review disclosure: Codex performed the exact-head analysis, and an independent reviewer agent compared this implementation with #3337 and adversarially checked persistence and mixed-version compatibility. I verified the source path, live state, and final severity.

[Astro-Han]

Thanks for preserving legacy backend keys on input. [P2] This decoder now also removes the field from Host responses, while the compatibility epoch remains unchanged. A current Client still requires backend, so a supported mixed-version path—such as updating a remote Host before its Client—can pass the epoch handshake and then tear down the connection when the first scheduled-task response fails decoding. Could we advance RUNTIME_HOST_COMPATIBILITY_EPOCH on the final merge base and add mixed-version coverage for the structured incompatibility path? Restoring backend as durable state is not necessary.

[yihanzhu]

Agreed. I rebased onto current main (epoch 33), bumped to 34, and added a Host-first mixed-version regression: a previous-epoch Client receives the structured incompatible handshake, then its scheduled-task query is rejected before domain admission. The legacy backend key remains input-tolerated and is not restored as durable state. Core (576), Runtime Host (1046), build, typecheck, lint, and format all pass. Updated in 0f46829. — Posted with Codex assistance.

[yihanzhu]

The review fix is pushed at 0f46829. GitHub created the new CI run with action_required and no jobs, so it needs maintainer workflow approval before checks can start: https://github.com/apache/maka/actions/runs/32482313598. Local Core, Runtime Host, build, typecheck, lint, and format checks are green. — Posted with Codex assistance.

[Astro-Han]

Thanks for addressing the compatibility boundary directly. Exact head 0f46829c4 advances the Runtime Host compatibility epoch from 33 to 34 for backend-free ScheduledTask responses, while preserving legacy input tolerance without restoring the removed field as canonical state. The Host-first mixed-version regression also verifies that a previous-epoch Client is rejected before any ScheduledTask command is admitted.

The original finding is resolved, and I found no remaining P0–P3 issues on this head.

AI-assisted review disclosure: OpenAI Codex reviewed the exact-head fix, compatibility authority, mixed-version handshake path, focused regression, current main epoch, and live GitHub state. I verified the evidence and made the final approval decision.