Add a `code_attack` technique variant that applies the code-completion system prompt

[u7k4rs6]

Follow-up from #1960, which added CodeAttackConverter and registered code_attack as a converter-only technique in scenario_techniques.py. The converter wraps the objective in a code-completion template, the core mechanism from Ren et al. (CodeAttack, Findings of ACL 2024, arXiv:2403.07865).

Gap: the paper also frames the session with a code-completion system prompt. The converter-only technique drops that framing. Per discussion on #1960 this was non-blocking and deferred (rlundeen2: "we can add techniques that also do the system prompt/framing").

Proposal: a variant technique that also applies the framing system prompt, ideally via a generic way to attach an objective-target system prompt to a technique rather than a bespoke attack class. On targets without system-prompt support it would lean on GenericSystemSquashNormalizer and the capability-handling ADAPT path to fold the framing into the user turn.

The framing seed (pyrit/datasets/executors/code_attack.yaml, removed in #1960) can be restored from git history.

[tejas0077]

Hi, I'm interested in working on this. Before I start, could a maintainer confirm the preferred approach specifically whether to add a new technique variant in scenario_techniques.py that sets a system_prompt on the target, or whether a more generic system-prompt attachment mechanism is preferred first?

[saisharan0103]

The repro details point to a clear gap: #1960 left code_attack as a converter-only technique, so the CodeAttack session framing from the paper is not applied. For a PR, I would start by adding a generic technique hook for an objective-target system prompt, then restore the removed pyrit/datasets/executors/code_attack.yaml seed and let unsupported targets flow through GenericSystemSquashNormalizer/ADAPT. Should the framed variant get a new technique name alongside code_attack?