Thread JaxiteWord keys through context generation and fix emitted ciphertext ops

[Zohaib58]

Change jaxiteword.gen_params to take public, secret, and evaluation keys, and
emit them into the generated ckks.CKKSParameters. Update the crypto-context
configuration pass so __generate_crypto_context accepts those three keys and
__configure_crypto_context only takes the crypto context.

Teach LWE-to-JaxiteWord lowering to add crypto context/eval-key arguments to
functions with crypto-typed arguments, update func.call operands for converted
callees, and lower CKKS rotations when a dynamic shift is defined by an arith
constant.

Rework the JaxiteWord Python emitter around tiled Polynomial values:

• emit func.call operations
• add _ensure_poly and _assign_poly helpers
• normalize ciphertext operands before add/sub/mul/square/rotate/rescale/decrypt
• use he_mul[level].mul for relined multiplication
• emit he_rescale for modulus reduction across levels
• implement plaintext add/sub against the c0 limb
• generate rotation keys via key_gen.gen_rotation_key
• store key material in generated CKKS params instead of mutating program init

Update JaxiteWord emitter/configure-context FileCheck tests and add 8x8 matvec
MLIR/Python artifacts for validating the emitted JaxiteWord path.

[j2kun]

I will take a closer look today. But to start, you should not check in these large generated python files (matvec_8x8_cross.py and matvec_8x8_jaxiteword.py). The lit tests should suffice for now, and then we can add a bazel-based macro (like

heir/tools/heir-jaxite.bzl

Line 7 in 1388538

def fhe_jaxite_lib(name, mlir_src, heir_opt_pass_flags = [], py_lib_target_name = "", tags = [], deps = [], **kwargs):

) to combine heir-opt, heir-translate, and wrapping up the resulting py_library/py_test rule.

[j2kun]

I am a bit confused why the codegen logic is so complicated all of a sudden. The JaxiteWord ops are supposed to be a direct mirror of the CROSS API, so each emitter should be at most 1-2 lines of code to call the corresponding API. But these emitters are full of reshaping, member accesses, etc. What happened?

[j2kun]

Doesn't the server need to generate parameters independently of any particular user? Taking a public/private/eval key as input seems like it would make it impossible to have a user-independent FHE program.

And for that matter, wouldn't you need to decide on all these parameters before generating key material? Surely the evaluation key depends on the data pre-computed by the crypto context at initialization...