fix: allow an explicit --execution-time to extend the plan end past the prod frontier

[nnqtruong]

Description

Why. --execution-time tells a plan "pretend it is now X". Today that only works in one direction: if prod's recorded intervals are newer than X, the plan end is clamped down to X — but if X is beyond the last interval recorded in prod, the plan end stays capped at the prod frontier and the flag is silently ignored. That's the behavior reported in #5640: with no model changes, sqlmesh plan --execution-time '2025-12-28' --auto-apply reports "No changes to plan" and fills nothing, even though 2025-12-26/27 are due. The confusing part for users is that the same command appears to work in dev and on a first deploy — only because no prod frontier exists yet to cap against — and that plan --run (which skips the caps) fills the intervals fine.

What. In Context.plan_builder(), when execution_time is explicitly provided, no explicit end is given, and the execution time is past the computed default end (the prod frontier), the default end and the per-model interval-end caps (end_override_per_model) are raised up to the execution time. This mirrors the existing precedent for explicit --end (which drops those caps entirely via PlanBuilder.override_end), and is bounded by the already-correct plan --run behavior: raising caps toward the explicit execution time cannot schedule anything the cap-free --run path wouldn't. No behavior changes when --execution-time isn't passed, when --end is given, on first deploys, or when the execution time is behind the frontier (the downward clamp is preserved).

Closes #5640

Test Plan

• New: test_plan_execution_time_ahead_of_prod_frontier — the issue scenario end-to-end on the sushi example (backfill required, plan end = execution time, intervals advance after apply; downward clamp still asserted).
• New: test_plan_execution_time_ahead_of_prod_frontier_matches_run_for_all_models — a daily+weekly project with different per-model frontiers; asserts plain plan --execution-time X reports byte-identical missing intervals to plan --run --execution-time X.
• New: test_plan_execution_time_ahead_of_prod_frontier_with_explicit_end — explicit --end + far-future execution time: backfill stops at the explicit end.
• Updated: test_plan_min_intervals — raw plan.end now equals the explicit execution time (1s past the old day-aligned frontier); comment explains why no interval computation changes.
• The new first test fails without the fix (assert plan.requires_backfill → False).
• Ran: targeted 9-test set, tests/core/test_context.py and tests/core/test_plan.py (-m "not slow and not docker"), the make fast-test fast component (2544 passed; 6 failures are local-only pyodbc/unixODBC driver import errors in test_connection_config.py, a module this PR doesn't touch), and the CLI repro from the issue before/after.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test)
• My commits are signed off (git commit -s) per the DCO