Update to CUDA 13.0 and fix logging initialization error

[aucahuasi]

• Upgrade base image from v2.43.0-12.8 to v2.50.0-13.0
• Update CI workflows to build CUDA 13.0 and 12.9 versions
• Change conda environment activation from rapids to base
• Fix AttributeError when LOG_LEVEL=TRACE by mapping unsupported log levels (TRACE, VERBOSE) to DEBUG with stderr warning

[lmeyerov]

For changing hard-coded evals, let's wait to land till current release goes out etc as we get into an awkward release posture

Another thought to land sooner and streamline going forward: Instead of manually changing constants identified here, if we make them variables set by the caller or passed in, then we can land whenever. Most of these are already args to beginwith. They can still default to old version, and the test is if the new version grabs the expected new passed in vals...

[aucahuasi]

Thanks for reviewing this PR!

hard coded

I didn't change any harcoded evals there, all those are params and I just updated their default values.
The graphistry ci job invokes the gak build passing the right params.

if we make them variables set by the caller or passed in, then we can land whenever.

Yes, indeed! This is the case here, those were always vars/params used by the parent job to build.

[lmeyerov]

Yes, I' saying instead of changing defaults here and relying on defaults, do not change any defaults here, and make the calling code branch (graphistry/graphistry) pass in the right things. Then we can land this whenever, and graphistry master can keep working too b/c old defaults still active.

We may still be relying on some hard-coded defaults here somewhere, if this pr can work on the new versions without any default val changes here, then we have better confidence it works and can land sooner, and less risk of being unable to patch release old versions

[aucahuasi]

Yes, I' saying instead of changing defaults here and relying on defaults, do not change any defaults here, and make the calling code branch (graphistry/graphistry) pass in the right things. Then we can land this whenever, and graphistry master can keep working too b/c old defaults still active.

Got it, good catch, let me think how we can handle the CUDA (11.8,12.8) vs (13.0,12.9) mismatch.

[aucahuasi]

Let's just wait until we finish the release so we can push this RAPIDS 25.10/CUDA13 branch after that.
You are right here, I think I would need to do many changes just to support the release + development CUDA versions [(11.8,12.8) and (13.0,12.9)].

[aucahuasi]

We may still be relying on some hard-coded defaults here somewhere, if this pr can work on the new versions without any default val changes here, then we have better confidence it works and can land sooner, and less risk of being unable to patch release old versions

I did this other PR #127 that allow us to pass cuda versions as args, once we merged that we will be able to support current branches and new rapids branches as well.