[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

Beginnen Sie in JSONDeserializeFactory.java bei den Zeilen 45-52 und untersuchen Sie, wie der zweite Parameter von JSON.deserialize in eine ClassRefExpressionVertex konvertiert wird. Verwenden Sie die bereitgestellte Type.forName-Reproduktion, um zu überprüfen, dass das dynamische Argument die Analyse nicht mehr abbricht. Als erledigt gilt dies, wenn der Einstiegspunkt ohne einen InternalExecutionError abgeschlossen wird und den Typ, der kein Klassenliteral ist, als unbestimmt behandelt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.