[BUG][code-analyzer] sfge: JSON.deserialize with a Type variable throws ClassCastException and aborts the entry point

### Have you tried to resolve this issue yourself first?

- [x] I confirm I have gone through the above steps and still have an issue to report.

### Bug Description

**Engine:** `sfge` (Salesforce Graph Engine) · **Rule:** `ApexFlsViolation` (DevPreview) · **Selector:** `--rule-selector sfge`

`JSONDeserializeFactory` assumes the second argument to `JSON.deserialize` is always a class literal, and casts without checking:

```java
// JSONDeserializeFactory.java:45-52
// This results in a CastExpression that wraps a MethodCallExpression. The
// second parameter is always
// a ClassRefExpressionVertex that denotes the Type
// (MyObject__c)JSON.deserialize(asJson, MyObject__c.class);

ApexValue.validateParameterSize(vertex, 2);
final ClassRefExpressionVertex classRefExpression =
(ClassRefExpressionVertex) vertex.getParameters().get(1);
```

The comment says "always", but `JSON.deserialize(String, System.Type)` accepts any `Type` expression, and dynamic deserialization via `Type.forName(...)` is a normal pattern. When the argument is a variable, the cast fails.

```apex
Type targetType = Type.forName('Account');
Object o = JSON.deserialize(body, targetType);
```

### Output / Logs

```shell
ClassCastException: class com.salesforce.graph.vertex.VariableExpressionVertex$Single cannot be cast to
class com.salesforce.graph.vertex.ClassRefExpressionVertex (...are in unnamed module of loader 'app'):
com.salesforce.graph.symbols.JSONDeserializeFactory.lambda$static$0(JSONDeserializeFactory.java:52);
com.salesforce.graph.ops.ApexStandardLibraryUtil.getStandardType(ApexStandardLibraryUtil.java:155);
com.salesforce.graph.symbols.PathScopeVisitor.afterVisit(PathScopeVisitor.java:1244); ...
```

### Steps To Reproduce

1. Create an empty SFDX project (`sfdx-project.json` with a single `force-app` package directory).
2. Add `force-app/main/default/classes/JsonDeserializeVarType.cls` with the class shown below, plus a standard `JsonDeserializeVarType.cls-meta.xml` (apiVersion 62.0).
3. Add `code-analyzer.yml`:
```yaml
engines:
sfge:
java_thread_timeout: 900000
java_thread_count: 4
```
4. Run:
```
sf code-analyzer run --rule-selector sfge --workspace . --config-file code-analyzer.yml
```
5. The run reports an `InternalExecutionError` for the entry point instead of analysing it. That entry point yields no `ApexFlsViolation` findings at all, and nothing in the summary indicates coverage was lost.

```apex
public with sharing class JsonDeserializeVarType {
@AuraEnabled
public static void run(String body) {
Type targetType = Type.forName('Account');
Object o = JSON.deserialize(body, targetType);
Account a = (Account) o;
insert a;
}
}
```

### Expected Behavior

When the type argument is not a `ClassRefExpressionVertex`, return an indeterminate value rather than throwing. The type genuinely is not statically known, which is a normal analysis outcome, not an engine error. An `instanceof` guard before the cast is sufficient.

### Operating System

macOS 26.5.2

### Salesforce CLI Version

@salesforce/cli/2.147.7 darwin-arm64 node-v24.5.0

### Code Analyzer Plugin (code-analyzer) Version

code-analyzer 5.15.0

### Node Version

v24.5.0

### Java Version

openjdk version "11.0.32" 2026-07-21

### Python Version

N/A

### Additional Context (Screenshots, Files, etc)

Worth prioritising beyond its frequency (1 signature / 1 entry point for us): `JSON.deserialize` into a runtime-chosen type is precisely the shape a taint-tracking engine most wants to reason about, and today it is the shape that reliably kills the analysis instead.

### Workaround

Use a class literal where the type is statically known (`JSON.deserialize(body, Account.class)`). No workaround exists when the target type is genuinely dynamic.

### Urgency

Moderate

Comienza en JSONDeserializeFactory.java alrededor de las líneas 45-52 e inspecciona cómo el segundo parámetro de JSON.deserialize se convierte en un ClassRefExpressionVertex. Usa la reproducción proporcionada de Type.forName para verificar que el argumento dinámico ya no aborta el análisis. Se considera terminado cuando el punto de entrada se completa sin un InternalExecutionError y trata el tipo que no es un literal de clase como indeterminado.

Escrito por el modelo de indexación a partir del texto del issue.