refactor(air): tighten MainTrace role

> This is the function which takes pre-padded traces right? Or is it possible to store non-power-of-two matrices, and then return the proper one? Basically, the invariants - and even the purpose - of MainTrace are a bit unclear.
>
> From my understanding, we want the following
> - The fast processor generates an execution trace, which is a structured log of all the operations the VM needs to prove
> - From this, we generate a witness trace, the RowMajorMatrix (for core and chiplets) passed to the prover. Passed this point, the processor doesn't need to inspect the row major matrices so it shouldn't need to read anything from the witness trace, since it can get the information from its execution trace. I would make it the responsibility of the processor to correctly pad the trace to the next power of two.
>
> We should figure out if all of these accessors are really necessary on this struct. I think a lot of them could be implemented on MainCols instead. These could be accessed by having a method on the main trace which returns `&MainCols` for a given row.
>
> The main purpose of this struct seems to mainly serve as a way of constructing a combined trace which pads the core or chiplets trace to the size of the other.
>
> This is obviously a larger refactor which we can address as a new sub-issue to #1763.

_Originally posted by @adr1anh in https://github.com/0xMiden/miden-vm/pull/3171#discussion_r3272715817_

Examinez la structure MainTrace dans le codebase, probablement dans un fichier comme `air/src/trace/main_trace.rs`. Comprenez son rôle actuel dans la combinaison et le remplissage des traces du cœur et des chiplets. Examinez le type MainCols pour voir quels accesseurs pourraient y être déplacés. L’objectif est de clarifier les invariants et de réduire les méthodes inutiles de MainTrace, en veillant à ce que le processeur gère le padding. Consultez le PR #3171 et l’issue #1763 associés pour le contexte.

Rédigé par le modèle d'indexation à partir du texte de l'issue.