Proposal: Decouple boundary logic from InteractiveViewer

### Use case

`InteractiveViewer` has boundary logic baked in, which makes it inflexible and blocks important features. The current approach forces clamping inside constraints, with no way for users to define custom boundary behavior.

* [[#57698](https://github.com/flutter/flutter/issues/57698)](https://github.com/flutter/flutter/issues/57698): Rotation requires complex, fragile math that attempt to fit the content into the boundary box. Most common use cases don't want rotated content to be box-clamped.
* [[#58042](https://github.com/flutter/flutter/issues/58042)](https://github.com/flutter/flutter/issues/58042): Overscroll/overpanning cannot be implemented with the current API because correction is applied immediately and hardcoded into the transform pipeline
* [[#145725](https://github.com/flutter/flutter/issues/145725)](https://github.com/flutter/flutter/issues/145725): Users cannot implement standard photo-viewer behavior, where panning is constrained to the child/image rect instead of the widget constraints.

### Proposal

Introduce a lower-level widget (e.g. `RawInteractiveViewer` or `UnconstrainedInteractiveViewer`) that:

* Handles gesture detection and transform math.
* Does **not** enforce boundaries.
* Expose the raw transform before boundary correction, so users can implement their own policy (e.g. clamp to parent, clamp to child rect, allow overscroll, soft bounce-back, etc.). This goes beyond TransformationController, which only exposes the post-corrected transform.

`InteractiveViewer` could then be built on top of this with the current “clamp to constraints” behavior to avoid breaking changes.

Start by reading the InteractiveViewer implementation and its current gesture, transform, and boundary-correction flow. Determine how a lower-level widget could expose the raw transform while preserving InteractiveViewer’s existing constraint-clamping behavior. Done means the proposal’s custom boundary policies are possible without breaking the current API.

Written by the indexing model from the issue text.