chore: raise the openjd-model floor to 0.11.6

[leongdl]

What was the problem/requirement? (What/Why)

Two things, one commit.

The dependency floor is a release behind. openjd-model 0.11.6 is the first
release that accepts an environment defining only onExit
(openjd-model 5b9c661, shipped in
chore(release): 0.11.6 (#340)).
This package enters and exits environments handed to it by a caller, so a
template the model previously rejected at validation is one it can now be given.
0.11.5 carried only an openjd-rs crate dependency bump.

A breaking change is currently queued to ship as a patch. #357 removed
extra_let_bindings from Session.enter_environment, Session.exit_environment
and Session.run_task. That parameter was public in released 0.11.0 — it entered
mainline in #333 (df96902) and first shipped in tag 0.10.11 — so removing it
is a backwards-incompatible public API change.

The squash commit for #357 (457a364) landed without a BREAKING CHANGE:
footer. With minor_tags = [] and feat in patch_tags, semantic-release reads
that commit as a patch. No release has been cut yet (0.11.0 is still the newest
tag), so the removal would ship as 0.11.1 and anyone pinned ~=0.11.0 would
pick it up silently. The README's versioning policy says MINOR is incremented for
backwards-incompatible public API changes.

What was the solution? (How)

Raise the floor to openjd-model >= 0.11.6,< 0.12, and carry the missing
BREAKING CHANGE: footer on this commit so the next release is cut as MINOR.

The upper bound is unchanged: 0.11.6 is the newest release, so < 0.12 still
holds. The floor comment is rewritten to lead with the 0.11.6 reason while
keeping the 0.11.4 (SerializedSymbolTable JSON transport) and 0.11.2
(EXPR/WRAP_ACTIONS model surface) rationale, both still load-bearing.

Please do not edit the squash commit message on merge. This branch is a
single commit, and the repo's squash settings are squash_merge_commit_title = PR_TITLE with squash_merge_commit_message = COMMIT_MESSAGES, so the footer and
sign-off carry through as-is. Dropping the footer puts the release back at
0.11.1.

What is the impact of this change?

Next release is 0.12.0 instead of 0.11.1. Verified, not inferred — ran
python-semantic-release 10.6.1 in --noop version --print mode against this
repo's own config, on a branch name matching branches.release:

Tree	Next version
mainline exactly as merged (457a364)	0.11.1
with this commit	0.12.0

major_on_zero = false keeps it inside 0.x, so this cannot cut 1.0.0.

Consumers installing from a resolver will need openjd-model 0.11.6 or newer.

Unrelated but worth flagging for whoever runs the release: python-semantic-release
10.6.1 fails with type object 'Actor' has no attribute 'name_email_regex' against
current GitPython. openjd-model hit this and pinned GitPython == 3.1.59
(12816ad).
This repo has no equivalent pin.

How was this change tested?

• Have you run the unit tests? Yes — pytest test/openjd against openjd-model
  0.11.6: 986 passed, 8 failed, 40 skipped, 16 xfailed.

All 8 failures are pre-existing and unrelated to the bump:

• 6 × test_subprocess.py::TestLoggingSubprocessSameUser::test_run_gracetime_when_process_ends_but_grandchild_uses_stdout — the parametrization shells out to bare python, which is not on this dev machine's PATH (FileNotFoundError: [Errno 2] ... 'python'). Environmental.
• 2 × sessions_v1/test_session_scenarios.py (env_file_let_bindings, let_host_context) — reproduced identically with openjd-model pinned back to 0.11.5, so 0.11.6 did not cause them.

Was this change documented?

• Are relevant docstrings in the code base updated? N/A — no code change. The
  dependency comment in pyproject.toml is updated to explain the new floor.

Is this a breaking change?

Yes, and that is the point of the footer. The break itself was made in #357,
not here; this commit gives it the version bump it needs.

Callers must stop passing extra_let_bindings to Session.enter_environment,
Session.exit_environment or Session.run_task, and deliver step-scope EXPR
let values through resolved_symtab instead — the resolved symbol table the
service already produces per step and per environment. step_name is unchanged
on both methods.

Does this change impact security?

No. Dependency floor and release metadata only; no new or modified files or
directories, no change to process or permission handling.

Cross-port to openjd-rs

• This change does not affect runtime behavior (docs / tests / tooling only)

Dependency constraint and commit metadata only. The API removal it versions was
already cross-ported as part of #357.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

The BREAKING CHANGE: footer will version the release correctly but will describe the wrong change in the CHANGELOG.

.semantic_release/CHANGELOG.md.j2 renders the breaking-changes section from commit.commit.summary only:

{% for commit in release["elements"]["breaking"] %}
* {{ commit.commit.summary[commit.commit.summary.find(": ")+1:].strip() }} (...)

It never reads commit.breaking_descriptions or the commit body, so the footer text — the part that actually explains that extra_let_bindings was removed from Session.enter_environment / exit_environment / run_task — is dropped. With squash_merge_commit_title = PR_TITLE, the summary is this PR title, so the 0.12.0 entry will read:

BREAKING CHANGES

• raise the openjd-model floor to 0.11.6

A consumer upgrading from 0.11.0 sees a dependency floor bump listed as the breaking change, with no mention of the removed parameter that will actually break their code. The version number is right; the migration signal is missing.

Worth considering either putting the API removal in the commit summary rather than the dependency bump, or extending the template to emit commit.breaking_descriptions so footers are not silently discarded.

[github-actions]

The onExit-only rationale does not appear to be a constraint this package can enforce, which makes this floor bump stricter than it needs to be.

The other floors named in this comment are genuine import-level requirements — evaluate_let_bindings, CancelationMethodDeferred, SerializedSymbolTable.from_json_str and friends are imported directly, so on an older model the package fails at import or attribute access. That is what a dependency floor is for.

openjd-model 0.11.6 is different in kind: 5b9c661 relaxes a validator on the ordinary-action path, and grepping src/ turns up no template decode or validation call at all (no parse_model, no decode_*_template, no model_validate) — the package receives already-constructed model objects from its caller. So whether an onExit-only environment is accepted is decided by whichever openjd-model performed the decode, in the caller's process. Raising this package's floor does not make that template decodable for anyone whose caller resolves an older model, and this package's own handling already tolerates the shape regardless of model version — _runner_env_script.py:189 treats a missing onEnter as a no-op success, and _session.py:967-974 skips the wrap lookup when onEnter is None.

The practical cost is that every consumer must now resolve openjd-model >= 0.11.6, and the < 0.12 ceiling means there is exactly one acceptable version. Given the release is being cut as 0.12.0 anyway, that is a narrow window to hand downstream resolvers for a reason that is not load-bearing here. Keeping the floor at 0.11.4 and noting 0.11.6 as the version a caller needs to decode such templates would achieve the same thing without the constraint.