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_

Look at the MainTrace struct in the codebase, likely in a file like `air/src/trace/main_trace.rs`. Understand its current role in combining and padding core and chiplet traces. Review the MainCols type to see which accessors could move there. The goal is to clarify invariants and reduce unnecessary methods on MainTrace, ensuring the processor handles padding. Check related PR #3171 and issue #1763 for context.

索引モデルが issue の本文から書いたものです。