sfge: path evaluation never converges on a ~40-field DTO mapper, silently abandoning every entry point that reaches it

### Summary

Graph Engine path evaluation never completes for a method shaped like an ordinary DTO mapper — a `for` loop that assigns ~40 fields from an SObject onto a new inner-class instance. Every `@AuraEnabled` entry point whose call graph reaches that method is abandoned with `Path evaluation timed out after N ms`, at any timeout value we tried.

The mapper is the main view builder for a customer community portal, so this is not an unusual corner of the codebase — it is on the hot path of most entry points.

### Versions

- `@salesforce/cli@2.146.3`
- `code-analyzer@5.15.0`
- Rule: `ApexFlsViolation` (`sfge`, DevPreview)
- Linux: GitHub-hosted `ubuntu-latest`, and reproduced in `node:22-bookworm` with OpenJDK 17
- Observed 2026-08-20

### The most important part: it fails silently

When path evaluation times out, the entry point is abandoned and **no findings are reported for it**. The scan then prints:

```
Found 0 violations.
```

and **exits 0**.

`Found 0 violations` is indistinguishable from *"0 violations in the parts that finished"*. We only discovered that ~5% of our entry points were never analysed because we had added a step that greps the run's own log for `Internal execution error`. Anyone gating CI on this rule without that grep is gating on an unknown subset of their code and has no way to know.

**This is the part we would most like fixed, independently of the convergence bug.** An abandoned entry point should be visible in the exit code or in a summary, not only in a log line.

### Isolation

We bisected by modifying a copy of the tree and re-running the identical command. Baseline is unmodified.

| # | Change under test | Elapsed | Timeout? |
|---|---|---|---|
| — | baseline | 344s | yes |
| A | deleted 2 classes downstream of the entry point | 341s | yes |
| B | replaced a per-character `if/else` chain with a `Map` lookup | 352s | yes |
| C | deleted **all 12 classes** in the downstream call tree | 360s | yes |
| D | baseline ×2 (determinism check) | 342s / 348s | yes |
| E | `sfge-disable-stack` on the entry points | 350s | yes |
| F | stubbed the body of the read method the entry point calls | **63s** | no |
| G | removed only the *call* to that read method | 258s | no |
| H | **stubbed the DTO mapper that read method calls** | **165s** | no |
| I | stubbed a sibling call | 347s | yes |
| J | stubbed another sibling call | 345s | yes |
| K | stubbed four more sibling calls | 340s | yes |

**H is the finding.** The offending method is reached as: entry point → read method → **DTO mapper**. Stubbing the mapper drops the run below the timeout so it cannot fire.

We then bisected *inside* the mapper. None of these had any effect (~340s each, i.e. the timeout still fired):

- the one reflective read, `(Id) record.getPopulatedFieldsAsMap().get('SomeField__c')`
- a call into another class returning a `Boolean`
- two short-circuit `&&` chains

So it does not appear to be any individual construct. What remains is the shape: **a loop assigning ~40 fields onto a newly constructed object**.

We attempted to test whether time scales with field count, but our patch produced invalid Apex for two of the three variants (the analyser ran fast and reported no errors, which we read as the class failing to parse rather than as a result). **We are not claiming the field count is the cause** — only that no single line in the method is, and that this is where it would be worth your engineers looking.

### `sfge-disable-stack` does not help

Documented here for others: putting `/* sfge-disable-stack ApexFlsViolation */` on the affected entry points changed nothing (E, 350s). The directive suppresses rule *evaluation*; the timeout happens earlier, during path *expansion*.

### Raising the timeout does not help either

`java_thread_timeout` was already raised from the 30s default to 300s for an unrelated entry point. The method above does not converge at 300s and, from the shape of it, would not converge at any practical value — so the timeout is spent in full and then the entry point is dropped regardless. Lowering it trades coverage for speed; raising it trades speed for nothing.

### Possibly related, same run

A different entry point in the same codebase throws, rather than timing out. It passes a `Map` into a service method:

```
Internal execution error while scanning entry point: .cls:739:
Graph Engine identified your source and sink, but you must manually verify
that you have a sanitizer in this path. [...]
Error and stacktrace: NullPointerException: null:
java.base/java.util.concurrent.ConcurrentSkipListMap.computeIfAbsent(ConcurrentSkipListMap.java:1459)
com.salesforce.graph.vertex.SyntheticTypedVertex.get(SyntheticTypedVertex.java:41)
com.salesforce.graph.symbols.apex.ApexMapValue.apply(ApexMapValue.java:188)
com.salesforce.graph.symbols.PathScopeVisitor.handleApexValueMethod(PathScopeVisitor.java:1487)
com.salesforce.graph.symbols.PathScopeVisitor.afterVisit(PathScopeVisitor.java:1242)
com.salesforce.graph.symbols.DefaultSymbolProviderVertexVisitor.afterVisit(DefaultSymbolProviderVertexVisitor.java:800)
```

We have also previously seen the engine throw on `Map` and on `Decimal.setScale`, and reshaped code to avoid both.

### What would help, in priority order

1. **A non-zero exit, or an explicit summary line, when entry points are abandoned.** Silent under-analysis is worse than a slow scan.
2. **A diagnostic for *why* expansion does not converge** — a path or branch count, or a verbose mode naming the expansion site. The only signal today is "it timed out", which is what forced the twelve-run bisection above.
3. The convergence fix itself.

### Outcome for us

We have removed `ApexFlsViolation` from our blocking gate and moved it to a nightly advisory report. The gate went from 344s to 13s. We would rather have the rule back on the gate, and will re-arm it if this is fixed.

Happy to run further bisections against a diagnostic build, or to share the method under NDA.

Reproduce the ApexFlsViolation scan with the entry point → read method → DTO mapper path and the ~40-field loop described in the issue. Start by tracing Graph Engine timeout and abandoned-entry handling around PathScopeVisitor and the listed SyntheticTypedVertex/ApexMapValue stack frames. Done should include an explicit summary or non-zero exit for abandoned entry points, plus a diagnostic or convergence fix for the mapper path.

Scritto dal modello di indicizzazione a partire dal testo della issue.