ut3_kronecker_weights
=====================

.. py:function:: t3toolbox.backend.ut3_operations.ut3_kronecker_weights(weights_A, weights_B)

   .. code-block:: python

      def ut3_kronecker_weights(
              weights_A: UT3WeightsData,  # (tucker_weight_supercore, tt_weight_supercore, masks)
              weights_B: UT3WeightsData,  # (tucker_weight_supercore, tt_weight_supercore, masks)
      ) -> UT3WeightsData:                # per-edge Kronecker: padded widths MULTIPLY, masks Kronecker


   Per-edge Kronecker product of two uniform weights -- the Hadamard (``⊙``) combine, where ranks
   multiply. Uniform twin of ``t3_kronecker_weights``.

   **Kronecker the weights, Kronecker the masks -- that is the whole operation.** Treat the mask as just
   another weight that happens to hold 0s and 1s: what we need is
   ``weight_AB * mask_AB == kron(weight_A * mask_A, weight_B * mask_B)``, and it is satisfied by
   ``weight_AB = kron(weight_A, weight_B)`` and ``mask_AB = kron(mask_A, mask_B)``, because elementwise
   multiply **commutes** with the Kronecker product: ``kron(a∘p, b∘q) = kron(a,b) ∘ kron(p,q)`` (the
   mixed-product property, for any vectors -- nothing here is special to booleans). So there is no mask
   cleverness: the same ``kron_last`` runs on both operands.

   Each edge is a **last-axis outer product, then reshape**: ``(wA ⊗ wB)[..., a*nB + b] = wA[..., a] ·
   wB[..., b]`` -- **A-major**, over the PADDED widths, with the shared ``(d,)+stack`` prefix broadcast.
   **This is the one real trap**: not ``np.kron``, which would Kronecker the mode/stack axes too (the
   ragged build hit exactly that). A-major must also agree with whatever core-combine pairs with it.

   The resulting mask is **not an interval** -- the real set is ``{a*nB + b : mask_A[a] and mask_B[b]}``,
   strided over the *padded* width ``nB``, so even two prefix inputs give holes (``{0,1}`` of 3 times
   ``{0}`` of 2 gives ``{0, 2}``; ``docs/uniform_masks_vs_ranks.md``). That is a description of the
   output, not a difficulty: it costs nothing here, and only obliges *consumers* to read the mask rather
   than slice a prefix. It cannot be flattened to a prefix of rank ``rA*rB``: slot ``a*nB + b`` with
   ``b >= rank_B`` holds ``wA[a] * <padding>``, so a prefix mask would claim padding as real data
   (phantom rank).

   Note there is currently **no uniform Hadamard** (``ut3_add`` exists; ``ut3_mult`` does not), so this
   op ships verified against the ragged oracle but without a uniform core-combine partner -- see
   ``docs/contributor/weighted_internals.md`` §3.