feat: add quantum memory layout

[Gmin2]

Closes #113

this adds the quantum counterpart to hhat_core, right next to it. The difference is that it counts qubits instead of bytes and uses no alignment or padding, primitives report their qubit count (@Bool is 1, up to @U8 at 8), structs sum their members back-to-back, and a two-variant enum takes one qubit. There's also a small cache so layouts aren't recomputed, a primitive instruction type that carries an ancilla count, and a public QuantumProgram that's built when a variable is cast and works out the total qubits (data plus ancillas) and the classical register size. Along the way I fixed a bug where any struct with quantum members panicked in the classical layout pass.

I checked it by driving the layout with the language's own examples: @bell_t comes out as 2 qubits (fields at 0 and 1), @polarization as 1, and a nested type as 7. Running the full @v:@bell_t example with a dummy @sync instruction gives two data qubits plus its ancillas and a one-bit creg (only @v.@t is cast), so totals move 2, 3, 4, 5 — matching the OpenQASM sketch in the issue. Arrays are still left as a todo!().

Generative AI/LLM disclosure

I used an AI assistant to help me understand how the existing type and layout system works, how Ty, TypeLayout and the classical LayoutCache fit together and how quantum types should map onto it (qubit counts, structs, enums, ancillas).

Code and Logic Architecture/Design:

• The code and logic architecture/design contain no generative AI/LLM
• The code and logic architecture/design are partially performed by generative AI/LLM
  • 60% performed by the author(s)
• The code and logic architecture/design are fully performed by generative AI/LLM

Code content:

• The code contains no generative AI/LLM work
• The code is partially written by generative AI/L
  • 50% performed by the author(s)
• The code is fully written by generative AI/LLM

Code review:

• The code review contains no generative AI/LLM
• The code review is partially done by generative AI/LLM
  • 100% performed by the author(s)
• The code review is fully done by generative AI/LLM

Code tests:

• The code tests contain no generative AI/LLM
• The code tests are partially written by generative AI/LLM
  • X% performed by the author(s)
• The code tests are fully written by generative AI/LLM

[Gmin2]

I have created the PR with main branch instead of arch-scafold branch

cc @Doomsk

[Doomsk]

Hey @Gmin2 thanks for opening this PR. You have signalled that this PR was partially done with help of an LLM. Can you replace the X% by an estimate?

Regarding your comment, it's better to have it merged to the arc_scaffold branch rather than the main one.

[Gmin2]

Can you replace the X% by an estimate?

Done

Regarding your comment, it's better to have it merged to the arc_scaffold branch rather than the main one.

Done

and also I had run a small example that was given in the haeder example in the issue and run it and it produce

primitive quantum types:
  QBool -> 1 qubit(s)
  QU2 -> 2 qubit(s)
  QU3 -> 3 qubit(s)
  QU4 -> 4 qubit(s)
  QU8 -> 8 qubit(s)

composite types:
  @bell_t { @s:@bool, @t:@bool } -> 2 qubits
      field #0 at qubit offset 0
      field #1 at qubit offset 1
  @polarization { @V, @H }     -> 1 qubit
  nested { @bell_t, @u4, @polarization } -> 7 qubits (2 + 4 + 1)

quantum program for @v:@bell_t:
data qubits: 2
ancilla qubits: 1
total qubits: 3
classical register: 1 bit (only @v.@t cast)

Should i also include the example ??

cc @Doomsk

[Doomsk]

@Gmin2 thanks! You can include as tests it they are relevant and add any other useful point you think is worth mentioning, such as why you chose the fields you chose from the QuantumProgram, and whether there's something missing from the current code or what you think can be done next once it is merged.

[Gmin2]

Hey @Doomsk why my pr was not reviewed at all??

[Doomsk]

@Gmin2 glad that you finally replied. I was waiting for the tests and you never replied.