[awennersteen]

Description of Change

Follow-up to #211. QRMI_QPU is only set in S_CTX_ALLOCATOR (sbatch, salloc). srun runs SPANK plugins in S_CTX_LOCAL, so a job submitted with srun --qpu=... reaches slurmctld without QRMI_QPU, and a job_submit plugin cannot see its QPU. This sets it in both contexts.

Evidence (Slurm 25.05.3)

• srun initialises the plugin stack with spank_init(NULL) (srun_job.c#L689), which uses S_TYPE_LOCAL (spank.c#L834-L840), reported to plugins as S_CTX_LOCAL (spank.c#L1911-L1912).
• spank_job_control_setenv() only rejects remote and slurmd contexts (spank.c#L2370-L2382). The spank(8) docs list the spank_job_control_* functions as available "from local context only".
• srun builds its allocation request with slurm_opt_create_job_desc() (allocate.c#L705), which copies spank_job_env into the job description sent to slurmctld (slurm_opt.c#L5795-L5802), as for sbatch and salloc.

Testing

On a Slurm 25.05.3 cluster, slurmctld at debug3 (which logs spank_job_env per submission), each command run with --qpu=PASQAL_LOCAL:

Command	main (#211)	this PR
srun	spank_job_env="_SLURM_SPANK_OPTION_spank_qrmi_qpu=PASQAL_LOCAL"	..., QRMI_QPU=PASQAL_LOCAL
salloc	..., QRMI_QPU=PASQAL_LOCAL	..., QRMI_QPU=PASQAL_LOCAL
sbatch	..., QRMI_QPU=PASQAL_LOCAL	..., QRMI_QPU=PASQAL_LOCAL

In srun inside an existing allocation the call only updates the step's spank_job_env; the job runs as before.

Note for job_submit.lua

Lua sees job_desc.spank_job_env as a table with 0-based keys (job_submit_lua.c#L723-L737), so the ipairs loop in the #211 description skips the first entry. Use pairs:

for _, kv in pairs(job_desc.spank_job_env or {}) do
    local qpu = kv:match("^QRMI_QPU=(.*)$")
end

[ohtanim]

lgtm. thanks