fix: force_operation_parentheses works under a parenthesised ancestor (#342)

[livingstaccato]

Fixes #342.

What

force_operation_parentheses exists to make precedence explicit, and it did so for a top-level expression. Inside one the caller had already parenthesised, it added nothing:

options = SerializationOptions(force_operation_parentheses=True)

loads("a = b + c * d\n",   serialization_options=options)["a"]  # '${b + (c * d)}'
loads("a = (b + c * d)\n", serialization_options=options)["a"]  # '${(b + c * d)}'  ← unchanged

So the documents most likely to want explicit precedence — the ones already carrying parentheses — got the least of it.

Why

inside_parentheses answers "did my immediate container already wrap me". _wrap_into_parentheses reads it to avoid doubling. Two places widened it to "some ancestor is parenthesised":

• ExprTermRule.serialize carried it down as self.parentheses or context.inside_parentheses, so one parenthesised term set it for its whole subtree;
• the binary, unary and conditional rules passed it unchanged to their operands, which nothing directly wraps.

Each term now sets the flag from its own self.parentheses, and the operation rules clear it for their operands.

What does not change

((b + c) * d) is not doubled, (b + c) * d keeps its single pair, and the option-less path emits exactly what it did before — asserted for six shapes, since that is the half most easily broken by a change like this.

With b=2, c=3, d=4, OpenTofu v1.12.5 evaluates both (b + c * d) and the (b + (c * d)) this produces to 14.

Merging

It touches the same code as #334 (hcl2/rules/expressions.py). Whichever of those lands first, this one needs a rebase rather than a merge — the overlaps are real edits to the same methods, not adjacent lines, so resolving them by hand risks losing one of the two fixes. Say the word and I will rebase and re-run the suite.

---

This pull request, and the investigation behind it, were produced by an AI assistant (Claude) working on behalf of the author. Please review with that provenance in mind.

[livingstaccato]

Please hold off on merging this one for now — I want to do another review pass over it before it goes in. Opened as a draft for that reason; I will mark it ready and say so here once I am done.

[livingstaccato]

Review pass done, so the hold above no longer applies — this is ready for review now.

Rebased on current main; GitHub reports it mergeable as it stands.

_{🤖 Drafted with Claude Code.}

[livingstaccato]

Brought up to date with current main (0f74596) — GitHub had this flagged as
conflicting, which was only CHANGELOG.md and the merge=union driver that the
web UI does not honour. This one conflicts with #334, which removes the context.modify() these
rules call (hcl2/rules/expressions.py), rather than with main.

Merge order. Eight of the twelve open PRs apply to main in sequence with no
conflict at all — verified by merging each and running the suite, not by
inspection:

#332 → #334 → #335 → #345 → #346 → #349 → #352 → #354

(1552 → 1563 → 1591 → 1627 → 1671 → 1696 → 1703 → 1711 passing, from a 1534
baseline; each adds its own tests.) The other four — #333, #348, #350, #351 —
conflict with siblings rather than with main, so no ordering avoids them.

A resolved integration of all twelve is on the fork if it is useful:
livingstaccato/python-hcl2:int/pyvider-hcl-9 — 1784 passing, ruff and mypy
clean. Not proposed as a PR; the twelve are more reviewable apart.

_{Drafted with the help of an LLM, working on behalf of the author.}