#84: temporal planner — sequential scheduling of durative-action domains

[hfoffani]

Closes #84.

Adds a temporal planner that actually solves durative-action domains — the
piece deliberately left out of 1.0. Until now durative actions were parsed,
grounded and checked for at start applicability (DurativeState), but no
planner scheduled them.

What it does

pddlpy/planning/temporal.py — registered as get("temporal"), declaring the
:durative-actions capability, behind the existing Planner ABC
(solve(dp) -> Plan | None).

• apply_durative(state, action) applies one grounded DurativeAction:
  1. at start conditions must hold in the current state;
  2. start effects apply at the start point;
  3. the over all invariant and at end conditions are checked against that
     mid-state (with no concurrency it persists for the whole duration);
  4. end effects apply at start + duration.
• TemporalPlanner runs uniform-cost search over accumulated duration and
  returns a TemporalPlan whose steps are ScheduledActions
  (action, start, duration, end); makespan doubles as the plan cost.
• Instantaneous actions participate as zero-duration steps, so mixed
  domains work.

Semantics & judgment calls

• Sequential v1: actions never overlap. A consequence worth stating: under
  sequential semantics over all / at end are constrained only by an
  action's own start effects — an action whose start effect breaks its own
  invariant is never executable. This is exactly the constraint an at-start-only
  checker cannot express, and the temporal-weld corpus demonstrates it: a
  naive planner would emit the cheaper quick-weld (which drops the clamp at
  start, violating over all (holding)), while the temporal planner correctly
  schedules steady-weld (makespan 6).
• Required concurrency is out of scope (match/cellar-style mandatory
  overlap) — a documented follow-up. Also out of scope per the issue: PDDL 3.x
  preferences and PDDL+ processes/events.
• The planner reuses the existing State (add-after-delete effect semantics)
  and the fail-fast requirement/capability guards, so it slots into the layer
  without touching the reference planners. Strict layering is preserved (no
  grammar import; tests/test_layering.py passes).

Corpus & tests

Two solvable durative domains with correct schedules, plus an unsolvable
variant:

• temporal-weld — over all genuinely constrains the plan (naive → invalid);
  temporal-weld-notorch — at end (torch-lit) unsatisfiable → no schedule.
• temporal-charge — mixed instantaneous (plug) + durative (charge-battery),
  makespan 4.

Full suite green at 100% coverage (202 tests, +11); ruff and mypy
(strict on pddlpy.planning.*) clean; make (grammar + all tests) green.

Note for reviewers

An ADL workstream (#10) is running in parallel and may conflict with this PR in
the planner registry and docs (README / docs/object-model.md) — worth
sequencing the merges.