skip FES checks on internal calls

[avinxshKD]

Resolves #7817

Changes

Added call depth tracking to skip FES param validation on internal p5 function calls. The decorator now sets _isUserCall flag and only validates at the outermost level. For async contexts (load* methods), added _internal() helper to suppress validation after await points.

Modified 5 shader loading functions in src/webgl/material.js to wrap post-await internal calls: loadFilterShader, loadMaterialShader, loadNormalShader, loadColorShader, loadStrokeShader.

Fixes the issue where users see FES warnings for internal p5 calls they didn't write (like createVector inside worldToScreen and avoids redundant param checking on already-validated internal calls.

Screenshots of the change

N/A - internal behavior change, no visual differences

PR Checklist

• npm run lint passes
• Inline reference is included / updated
• Unit tests are included / updated

[avinxshKD]

@davepagurek hey let me know if any adjustments needed, happy to work thanks

[ksen0]

Seems like this line would result in all calls being internal? What am I missing? I understood it but maybe it would be nice to add a comment for this block and the block above, noting that if one logic is updated the other should probably be reviewed, as they are similar but not quite same.

[avinxshKD]

@ksen0 Hey, hve added cross-reference comments linking the two blocks, both now have NOTE lines pointing to each other.

[davepagurek]

Nice! While we're at it, can we do the other known methods? In the reference it looks like that means loadModel, loadFont, loadImage, loadBlob, loadBytes, loadJSON, loadStrings, loadTable, and loadXML

[avinxshKD]

hey @davepagurek you mean _internal() applied to ALL load* methods, not just the shader ones.Right??

checked all of them:

• loadJSON, loadStrings, loadTable, loadXML, loadBytes, loadBlob — no this. calls at all post-await, they just return data or pass to successCallback
• loadImage : works on the p5.Image instance and browser APIs, no this.method() calls
• loadFont : uses fn.parseFontData directly (bypasses the decorator entirely) and a module-level create() helper
• loadModel : operates on the Geometry instance (model.normalize() etc), no this.method() calls

None of them hit a decorated p5.prototype method after an await, so wrapping wouldn't change behavior. The 5 shader loaders in material.js are the only ones that actually call this.buildXxxShader() / this.createFilterShader() post-await

Should I add wrapping to the others anyway for consistency/future-proofing, or is the current scope (just the shader loaders) what you had in mind? Want to make sure I'm not missing somethin

[avinxshKD]

@davepagurek hey pls also have a look when you get chance, implemented the .at() approach we discussed for the 2.0 #8512. As we have already merged for the main. Thanks again