chore(release): 0.33.0

[client-software-ci]

0.33.0 (2026-08-21)

BREAKING CHANGES

• The total-disk-used-percent metric now reports values on a 0-100 scale instead of a 0.0-1.0 fraction. Previously, a 25% full disk was incorrectly reported as 0.25; it now correctly reports as 25. (fix!: report total-disk-used-percent on a 0-100 scale #1067)

Features

• The worker agent now accepts and forwards the resolvedSymbolTable field from BatchGetJobEntity step and environment details to the session runtime, enabling pre-resolved EXPR symbols (Job.Name, Param., RawParam., step let values) to be used in sessions. (feat: accept and forward resolvedSymbolTable to the Rust session runtime #1063)
• Session extension enablement is now driven by the job's extensions declaration from BatchGetJobEntity. Jobs can explicitly declare which extensions to enable, with backward compatibility maintained when the field is absent. (feat: drive session extension enablement from the job's declaration #1062)
• Added support for 8 new EXPR parameter types (bool, rangeExpr, stringList, pathList, intList, floatList, boolList, intListList) in API response parsing. Jobs using these parameter types will no longer crash the session. (feat: add support for EXPR parameter types in API response parsing #1064)

Bug Fixes

• Fixed a crash when jobs use EXPR parameter types (e.g., bool, rangeExpr, list types) — entity validation previously rejected these types before they could be parsed. (fix: accept EXPR parameter types in job details entity validation #1065)
• Fixed parameter type resolution for LIST[*] job parameter types (LIST_STRING, LIST_INT, etc.) which previously failed with a "type not defined" error due to incorrect enum member lookup. (fix: resolve Rust parameter type enum members by name, not value #1066)
• Step-scoped environments now correctly receive their step's name and let bindings. (fix: give step-scoped environments their step's name and let bindings #1061)
• On Windows, materialized embedded files now have explicit ACLs granting the agent user full control and the job user read access, fixing issues where files could be unreadable or over-exposed when NTFS inheritance is misconfigured. (fix: set explicit Windows ACL on materialized embedded files #1059)

[github-actions]

This release commit adds a second ## 0.33.0 section while ## 0.33.0 (2026-08-20) already exists directly below (added by #1069). The CHANGELOG now has two headings for the same version, and every entry in the new block is a duplicate of one in the older block — #1067, #1063, #1062, #1064, #1065, #1066, #1061, #1059 all appear twice, just reworded.

The likely cause: the only commit since the previous release was 1c45a4c fix(test): relax session root dir assertion for openjd-sessions 0.11.0. If the 0.33.0 tag from #1069 was never created/pushed, semantic-release would re-scan the same commit range, recompute the identical version, and re-emit all of the same entries. Note also that test is not in patch_tags/minor_tags in pyproject.toml, so a test-only commit should not have triggered a release at all.

Worth confirming before merge, since the version is unchanged from the last release: a build from this commit would collide with the already-published 0.33.0 artifact. If the intent was to supersede the earlier section, the old one should be removed rather than stacked (but see the separate note about the #1068 entry that only exists in the old block).

[github-actions]

This new BREAKING CHANGES block drops content that the existing 0.33.0 (2026-08-20) block has, so it is not a superset of what it duplicates:

1. The chore: bump openjd-sessions to 0.11.0 #1068 breaking change is missing entirely. The older block documents: "Session working directory naming on Windows has changed (session ID prefix removed, embedded_files renamed to ef) for MAX_PATH compliance." That is a genuine user-facing behavior change (ebb131b chore: bump openjd-sessions to 0.11.0 (#1068)), and it appears nowhere in the new block. Since chore is not in patch_tags/minor_tags, semantic-release would not pick it up automatically — it was presumably added by hand to the previous section, and regenerating lost it.

2. The fix!: report total-disk-used-percent on a 0-100 scale #1067 entry lost its migration guidance. The older wording ends with "If you have alerts or dashboards based on this metric, update your thresholds accordingly." That actionable sentence is exactly what a reader needs from a BREAKING CHANGES entry, and the new phrasing omits it.

If the two 0.33.0 sections get collapsed into one, please make sure the surviving section keeps the #1068 entry and the #1067 threshold guidance.