Fix thread-safety bug for user-defined epsilon in meepgeom.cpp

[oskooi]

Root cause: The has_user_materials flag in the geom_epsilon constructor (src/meepgeom.cpp:661) is initialized to false and only checks geometry objects' materials. It does not check the global default_material, which is where material_function=my_material_func (a Python callback passed at the Simulation level) ends up.

This causes is_thread_safe() to return true, so set_chi1inv takes the OMP parallel path (PLOOP_OVER_IVECS_C with collapse(3)). Multiple OMP threads then concurrently call get_material_pt, which invokes the Python callback (md->user_func(...)) from non-main threads. Python's interpreter is not safe to call from arbitrary native threads, which causes the segfault in test_user_defined_material.py.

Fix: Initialize has_user_materials by also checking whether default_material is a MATERIAL_USER. This ensures the serial code path is used when the default material is a Python callback.

Validation: test_user_defined_material.py now passes with OMP_NUM_THREADS=1, 2, and 4.