[BUG][code-analyzer] sfge: SObjectType.newSObject(Id) and newSObject(Id, Boolean) abort 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`

`SObjectType._applyMethod` hardcodes a zero-parameter assertion for `newSObject`:

```java
// SObjectType.java:128-131
} else if (METHOD_NEW_S_OBJECT.equalsIgnoreCase(methodName)) {
validateParameterSize(invocableExpression, 0);
```

Apex has three overloads: `newSObject()`, `newSObject(Id)`, and `newSObject(Id recordTypeId, Boolean loadDefaults)`. Only the zero-argument form is accepted; the other two throw at `ApexValue.java:610`.

```apex
Schema.SObjectType t = Account.SObjectType;
SObject s = t.newSObject(recordTypeId, true);
```

### Output / Logs

```shell
UnexpectedException: MethodCallExpressionVertex{fullMethodName=t.newSObject, ... MethodName=newSObject}:
com.salesforce.graph.symbols.apex.ApexValue.validateParameterSize(ApexValue.java:610);
com.salesforce.graph.symbols.apex.schema.SObjectType._applyMethod(SObjectType.java:131);
com.salesforce.graph.symbols.apex.schema.SObjectType.executeMethod(SObjectType.java:121); ...
```

### 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/NewSObjectArgs.cls` with the class shown below, plus a standard `NewSObjectArgs.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 NewSObjectArgs {
@AuraEnabled
public static void run(Id recordTypeId) {
Schema.SObjectType t = Account.SObjectType;
SObject s = t.newSObject(recordTypeId, true);
insert s;
}
}
```

### Expected Behavior

All three `newSObject` overloads should be accepted. Suggested fix: `validateParameterSizes(invocableExpression, 0, 1, 2)` — that helper already exists immediately below `validateParameterSize` in `ApexValue.java` and is documented for exactly this case ("Used when a method has overloads with different numbers of arguments").

### 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)

In our codebase: 8 occurrences across 4 distinct `@AuraEnabled` entry points.

Previously reported as #1175 (`objType.newSobject((Id) recordId)`, the 1-argument overload), closed NOT_PLANNED as a duplicate in 2024. Still reproduces on 5.15.0.

### Workaround

Use `new Account()` where the concrete type is known, or drop the record-type argument and assign `RecordTypeId` as a field afterwards. Neither is possible when the SObject type is genuinely dynamic.

### Urgency

Moderate

Read SObjectType.java around _applyMethod and ApexValue.java around validateParameterSize and validateParameterSizes. Run the sfge reproduction with the supplied code-analyzer.yml and verify that all three newSObject overloads are accepted, the entry point no longer aborts, and analysis can produce findings.

Written by the indexing model from the issue text.