Refine/validate anon script injection in xnat core GradualDicomImporter

[kelseym]

Context

2.0.0 Batch Transfer lets a user supply a custom DicomEdit script per Reimport by forwarding
it as the xnat-web importer param GradualDicomImporter.ANON_SCRIPT_PARAM ("Anon-Script")
(importExperiment → params.put("Anon-Script", …) → DicomZipImporter; plugin only forwards,
apply lives in xnat-web ~1.9.3.5, feature-detected via TransferCapabilitiesService). This spike
decides whether to build on that param.

Goal 1 — Is the param sufficient?

• Confirm Anon-Script is actually applied on the inline (action=commit) Reimport path, not ignored.
• How it composes with the destination project/site anon script (override vs chain vs conflict).
• Gaps a single param can't express (lookup/CSV substitution, multi-file consistency, reporting which script ran).

Goal 2 — Security concerns & mitigations

User-supplied scripts promote anon authorship from admins to any reimporting user, run in the XNAT JVM. Assess + mitigate:

• Is DE4 enabled in core XNAT 1.10?
• PHI risk from an empty/bad script; safe default + clear UI.

Recommended guardrails already drafted in docs/2.0.0-anon-thread-safety.md (Phase 1B) and docs/2.0.0-implementation-plan.md.

Deliverables

• Findings on Goal 1 (sufficient? gaps?) and Goal 2 (threats → mitigations, plugin-side vs upstream xnat-web).
• Go/no-go on Anon-Script as-is, minimum guardrails before enabling, and whether to ship admin-gated first.

References

docs/2.0.0-anon-thread-safety.md, docs/2.0.0-implementation-plan.md, docs/2.0.0-rest-api.md, docs/2.0.0-anon-script-pathway.html; xnat-web GradualDicomImporter.ANON_SCRIPT_PARAM (≈1.9.3.5); TransferCapabilitiesService.

[kelseym]

Added XXX-322 to address getURL security concern