docs(jira): document custom fields, ticket templates, and test render

Extend the Jira integrator guide with the mapping features shipped in the
Jira work:

- Custom Fields: source / value / vendor-field / application-point model,
  including the Vendor Field display-name -> internal-id picker
  (e.g. "DD Close Justification" -> customfield_10255) and transition-scoped
  fields (e.g. a resolution required on close).
- Ticket Templates: customer-authored Finding & Finding Group summary and
  description with built-in-default fallback, plus Test render to preview
  output against sample data before saving.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: Maffooch

docs/content/issue_tracking/pro_integration/integrations_toolreference.md

@@ -221,7 +221,16 @@ Statuses vary per project workflow, so these defaults are meant to be edited to
 
 ### Custom Fields (optional)
 
-You can map additional Jira fields (for example a required `resolution` on close, or `labels`) in the mapping's **Custom Fields** step. Each mapping specifies where the value comes from (a static value or an attribute of the Finding/Test/Engagement/Asset), the Jira field to set, and an **application point** that controls *when* the field is sent — on ticket creation, on every update, or as part of a specific status transition (for example, sending a Jira `resolution` alongside the transition that closes the issue).
+You can map additional Jira fields — for example a required `resolution` on close, or `labels` — in the mapping's **Custom Fields** step. Each custom-field mapping has four parts:
+
+- **Source** — where the value comes from: an attribute of the **Finding**, **Test**, **Engagement**, or **Asset** being pushed, or a **Static value**.
+- **Value** — for an object source, the specific attribute to read, chosen from a list of that object's fields with human-readable labels (for example *Severity*, *CVE*, *Mitigation*). For a **Static value** source this is a free-text box you type the literal value into.
+- **Vendor Field** — the Jira field to write to. Because DefectDojo can read Jira's field catalog, this is a searchable picker that lists each field by its **display name** and resolves it to the internal id for you — so you select *DD Close Justification* and DefectDojo stores `customfield_10255`. The picker is populated from the connection, so it works once the connection is saved and validated.
+- **Application point** — *when* to send the field: on **ticket creation**, on **every update**, or as part of a specific status **transition** (Active / Closed / False Positive / Risk Accepted). A transition-scoped field is sent as part of that transition's edit — this is how you supply a value Jira only accepts on a transition screen, most commonly a `resolution` your workflow requires when an issue is resolved.
+
+### Ticket Templates (optional)
+
+By default Jira issues use DefectDojo's built-in title and body. To customize them, attach a **Ticket Template** to the mapping in its **Ticket Template** step. A template defines four independently-optional pieces — the **Finding** summary and description, and the **Finding Group** summary and description. Any piece left blank falls back to the built-in default, so you can override just the title, just the body, or all four. Use **Test render** in the template editor to preview the rendered output against sample data — catching mistakes such as unknown placeholders or values that exceed a field's length limit — before saving. If a template is later deleted, the mappings that used it revert to the built-in defaults automatically.
 
 ### How it works