Seal the `UnaryOperator`/`Negative` hierarchy (`@internal` + finalize) — replaces dangling #83

[MidnightDesign]

Scoped for the 0.3.0 breaking release.

Problem

UnaryOperator (src/UnaryOperator.php:40) is a public abstract base kept on the promised surface by omission: it carries no @internal, and its __toString() (:49) and equals() (:58) are non-final. Its only concrete leaf, Negative (src/Negative.php:13), is already final — so what pins the hierarchy open is the members Negative inherits ($expression, __toString, equals, token), published before the base class existed. Its counterpart BinaryOperator is already sealed exactly the way this one should be (@internal + finalized __toString/equals).

The class's own docblock (lines 20-38) documents this as the intended end state but defers it:

marking the hierarchy @internal is a backward compatibility break and waits for the next major; tracked as eventjet/ausdruck#83.

Two problems with that deferral:

1. The #83 reference is dangling — there is no issue or PR #83 in this repo. This ticket replaces it.
2. "Next major" contradicts our own policy. Per docs/BACKWARD-COMPATIBILITY.md, on the 0.x line the minor is the compatibility boundary — 0.3.0 is the breaking window, the 0.x equivalent of a major. If this waits for a literal 1.0, it may wait years. The docblock wording predates the written policy.

Decision needed

Confirm we seal in 0.3.0 (my recommendation) rather than deferring to 1.0. If confirmed, also fix the stale "next major" wording in the docblock.

Proposed change

• Mark UnaryOperator and Negative @internal + @psalm-internal Eventjet\Ausdruck.
• Finalize UnaryOperator::__toString() and equals() to match BinaryOperator.

BC impact

Structural break: removes Negative/UnaryOperator and their inherited members from the public API and finalizes previously-published methods. Per policy this is exactly the "finalizing a published method breaks BC even on a final class" case — it can only land in a breaking minor.