fix(peft): follow TE's _GroupedLinear contract instead of pinning one layout

[yueming-yuan]

Problem

PEFT._forward_te_grouped_linear calls transformer_engine's private
_GroupedLinear directly. It was written against TE ≤ 2.14, and TE has moved that
contract twice since:

TE	signature	non_tensor_args	returns
≤ 2.14	forward(ctx, inp, non_tensor_args, *weights_and_biases)	21 fields, m_splits first, module near the end	Tensor
2.15 / 2.16	same	22 — module → weight_workspaces + cache_weight	Tensor
≥ 2.17	forward(ctx, inp, **m_splits**, non_tensor_args, *weights_and_biases)	21 — m_splits promoted out of the tuple	(Tensor, list)

On TE 2.17 the old call passes only two leading positionals, so everything shifts by
one: the non_tensor_args tuple binds to the m_splits parameter and weight[0]
binds to non_tensor_args. TE then unpacks that weight tensor, iterating its
first dimension, and the failure surfaces far from its cause:

File "transformer_engine/pytorch/module/grouped_linear.py", line 405, in forward
ValueError: not enough values to unpack (expected 21, got 16)

16 is the weight tensor's dim-0, not any tuple length — which is what makes this
one confusing to chase.

Multi-LoRA on grouped MoE experts is therefore broken on TE ≥ 2.17, and was already
wrong on 2.15/2.16 (they want 22 fields). Hit while bumping miles to
TransformerEngine 2.17.0.

Approach

A version table would silently misalign again the next time TE moves — the same
failure mode, just later. Instead this derives the contract from the TE that is
actually installed:

• _te_grouped_linear_contract() reads is m_splits positional? from
  inspect.signature, and the tuple field names from the = non_tensor_args
  unpack via inspect.getsource.
• The call site builds the tuple by name from a dict covering every field any of
  these releases asks for, and raises a named RuntimeError listing the unknown
  field if TE adds one.
• The result is normalised so both the Tensor and (Tensor, list) return forms work.

Net effect: a future TE change becomes an explicit error naming the field, instead of
a misaligned tuple surfacing as an unrelated unpack error inside TE.

Note weight_workspaces / cache_weight are passed empty/False: this shim always
passes is_first_microbatch=None, so no fp8 workspace caching happens on either the
old (module) or new (explicit workspaces) contract.

Verification

Checked offline against the 2.14.0 / 2.15.0 / 2.16.0 / 2.17.0 wheels:

TE 2.14.0: m_splits positional=False  fields=21  first=m_splits
TE 2.15.0: m_splits positional=False  fields=22  first=m_splits
TE 2.16.0: m_splits positional=False  fields=22  first=m_splits
TE 2.17.0: m_splits positional=True   fields=21  first=use_bias

and the supplied field dict covers every field in all four (no gaps). Repo
pre-commit passes.

I do not have a GPU box to run the grouped-MoE LoRA path end to end — the arity and
ordering are verified statically against the real wheels, but a functional run on
TE 2.17 before merge would be worth it.