[New Rule] JSP File Creation by Java Process

## Description

Detects a `java` process creating or modifying a `.jsp`/`.jspx`/`.jspf` file, a common webshell-drop pattern following exploitation of a Java web application (e.g. Spring4Shell-class vulnerabilities, various Struts CVEs). This is deliberately CVE-agnostic: it covers the underlying durable behavior (a Java process writing a JSP file) regardless of which specific vulnerability got the attacker to that point, rather than a single upload-endpoint sequence for one CVE.

Checked for overlap before proposing: the generic `persistence_webserver_unusual_file_creation` (`new_terms`) rule already partially covers `java` writing `.jsp`, but as a `new_terms` rule it only alerts once per new path/host combination. It isn't a dedicated, always-firing, risk-scored rule the way the WordPress-equivalent webshell rule (`persistence_php_web_shell_creation_associated_with_web_server_process`, or similar) is for PHP. This rule fills that specific gap for the Java/JSP case.

**Behavior-based**, not IOC-based: matches on process/file-type behavior, not a specific hash/indicator.

**Real testing performed** (isolated single-variable test, not just reasoning): compiled and ran a real Java program that writes a `.jsp` file via `java.io.FileWriter`, captured via a real file-creation-audit watch. As a negative control, the same program was also run writing a `.log` file instead (isolating file extension as the only variable); the `.log` write does not match. This confirms the rule's scoping is precise: it keys specifically on file extension, not merely "any file write by a java process."

**Known false-positive class, documented in the rule itself**: Java application servers (Tomcat, JBoss/WildFly) legitimately compile/write `.jsp` files internally as part of JSP-to-servlet translation and caching (e.g. `work/Catalina/...` directories), or during a real application deployment. Recommend scoping exceptions to known JSP work/cache directories in noisy environments.

## Target Ruleset
linux

## Target Rule Type
Event Correlation (EQL)

## Tested ECS Version
Validated against the `logs-endpoint.events.file*` schema (Elastic Defend / ECS file fieldset). Real capture was performed via Auditbeat file-watch (this host's kernel doesn't support Elastic Defend's eBPF sensor) and reshaped into the equivalent ECS `file` event schema for validation, noted transparently rather than presented as a live Elastic Defend capture.

## Query

```eql
file where host.os.type == "linux" and event.type in ("creation", "change") and
process.name == "java" and file.extension in ("jsp", "jspx", "jspf")
```

## New fields required in ECS/data sources for this rule?
None. Uses only standard `file.extension`, `process.name`, `event.type` ECS fields already present in `logs-endpoint.events.file*`.

## Related issues or PRs
None yet. First issue in a small batch from a personal detection-gap research project (real-telemetry validated throughout, see example data below).

## References
- https://attack.mitre.org/techniques/T1505/003/
- https://github.com/splunk/security_content (equivalent JSP-webshell detections in Splunk's own content, referenced for cross-vendor precedent)

## Redacted Example Data

True positive (real, reshaped from an Auditbeat file-watch capture into ECS file-event shape):
```json
{
"@timestamp": "2026-08-05T21:36:37.586Z",
"host": { "os": { "type": "linux" } },
"event": { "category": ["file"], "type": ["creation"], "action": "creation" },
"process": {
"name": "java",
"executable": "/usr/lib/jvm/java-26-openjdk/bin/java",
"args": ["java", "WriteJsp"]
},
"file": {
"name": "shell.jsp",
"extension": "jsp",
"path": "/var/www/webapps/app/shell.jsp"
}
}
```

Negative control (real, same program, same process, writing a `.log` file instead; does not match since the extension condition fails):
```json
{
"event": { "category": ["file"], "type": ["creation"], "action": "creation" },
"process": { "name": "java", "executable": "/usr/lib/jvm/java-26-openjdk/bin/java" },
"file": { "name": "output.log", "extension": "log", "path": "/var/www/webapps/app/output.log" }
}
```

Start with the linux ruleset and Event Correlation (EQL) rule conventions, then review the proposed query and its required ECS fields. Validate the Java JSP/JSPX/JSPF positive case, the .log negative control, and the documented application-server false-positive class against the logs-endpoint.events.file* schema.

Written by the indexing model from the issue text.