PinGuard Updates

[k3ldar]

PinGuard currently treats input-only GPIOs (e.g. ESP32 GPIO34–39) as PinCategory::Advisory. In strict mode (AllowAdvisory unset) this makes validate() return AdvisoryBlocked even for input uses (e.g. PinUse::Input/PinUse::SpiMiso/sensor ADC), even though the comments/docs say these pins are only invalid for output. Consider modelling input-only separately (safe for input, hard-block only when requiresOutput(use)), or special-casing advisory+input-only so it bypasses the advisory gate when needsOutput == false

[k3ldar]

For the ESP32-S3 table, GPIO45/46 are marked Advisory with a comment that validate() will promote them to Hard for output uses, but _inputOnlyMin/_inputOnlyMax are set so the range check never matches. As a result, GPIO45/46 can become allowed for output when AllowAdvisory is enabled, even though they are input-only on S3. Set the input-only range to cover 45–46 or add an explicit per-pin input-only check for the S3 variant.

[k3ldar]

The README describes PinGuard as rejecting flash-reserved, input-only, and strapping pins “at the point of assignment” in general. In the current code, PinGuard checks are implemented for some config setters (SPI, SD CS, relay pins, Nextion pins, etc.) but sensor pin assignment via S4 does not use PinGuard, and input-only handling is currently more nuanced (and affected by strict/advisory mode). Consider narrowing this description to the specific commands/config paths that are actually guarded, or extending PinGuard coverage to sensor pin setters to match the claim.