[PyTorch FE] Restore dynamic batch in window-reverse view shapes

[evkotov]

Problem

SwinIR-style window_reverse computes the batch as plain Python arithmetic:

B = int(windows.shape[0] / (H * W / ws / ws))
x = windows.view(B, H // ws, W // ws, ws, ws, -1)

Under torch.jit.trace the int(...) collapses to a literal. In the IR the
view shape becomes a Concat where only the spatial dims stay live (aten::size),
the leading batch is a baked Constant, and the channel is the trailing -1:

view(windows, [ B=Const(1), H//ws, W//ws, 8, 8, Const(-1) ])
                baked        live   live              infer

At the traced batch=1 this is correct:

windows = (361, 8, 8, 180),  total = 4_158_720
H//ws = W//ws = 19  (live)
known product = 1 * 19 * 19 * 8 * 8 = 23_104
-1 = 4_158_720 / 23_104 = 180   -> channel 180, correct

After model.reshape(batch=2) the input becomes (2, 3, 152, 152). The spatial
dims do not depend on batch, so the live H//ws, W//ws stay 19, 19, and the
leading Const(1) stays 1 (it is a literal with no input for reshape to rewrite):

windows = (722, 8, 8, 180),  total = 8_317_440   (twice the elements)
shape   = (1, 19, 19, 8, 8, -1)                  (leading still 1)
known product = 1 * 19 * 19 * 8 * 8 = 23_104     (unchanged)
-1 = 8_317_440 / 23_104 = 360                     (was 180)

The doubled element count divides by the same known product, so the only free
axis (-1) must absorb the extra factor of 2: the batch leaks into the channel,
180 -> 360, and the window grid is scrambled.

The corruption is silent because the final view rebuilds a correct shape -- its
batch is live and its channel is the literal embed_dim:

Reshape_8: [1, 19, 19, 8, 8, 360]
permute  : [1, 19, 8, 19, 8, 360]
Reshape_9 = view(1, H, W, -1) -> [1, 152, 152, 360]
final view(B, H*W, C) -> [2, 23104, 180]   shape correct, data wrong

Compilation, inference, and output shapes all pass; only the values are wrong
(max_abs_diff ~3.47 on the SwinIR_Classical models at batch=2).

Fix

Add ReshapeBatchDimResolver, a PyTorch-FE ModelPass run in normalize().
For a reshape carrying the window-reverse signature (leading positive-int
constant, exactly one trailing -1, at least one dynamic interior dim) it frees
the leading dim to -1 and pins the channel to its batch-independent value as a
Constant, so the batch is inferred from the real element count and no longer
leaks into the channel.

The channel is recovered by a deterministic walk-back rather than OV shape
inference: window_reverse uses two chained views and the second takes its data
through a permute whose output stays dynamic. The pass walks back from the data
to a static last dim, through a last-axis-preserving Transpose, or to a view
already selected for rewrite.

Two guards keep it from touching ordinary reshapes that share the structure:

• if the output last dim is statically known, it must equal the recovered channel;
• on the direct path the rewrite must only re-partition the leading dim and keep
  the data's entire trailing block, which rejects merge/split reshapes such as
  view(1, T//2, -1) whose -1 spans more than the data's last dim.

Tickets:

• 172206

[mvafin]

This is not a good fix. The problem is in model, the model is not-reshapable. @evkotov please check the actual pytorch model code, does it really supports any other batch then 1? We also have SmartReshape transformations, maybe it can be covered there?

[evkotov]

created #36574 with alternative approach with fix in SmartReshape