Expose configurableOptions metadata on rule instances in the UMD build

[CamilleGuillory]

Description

Third-party consumers of the UMD build (SFIr) need to dynamically discover rule configuration capabilities. The source code already has the ConfigurableOption interface and rules already declare their configurableOptions, but this metadata doesn't survive into the published UMD bundle.

Current behavior

• getRules() returns rule instances with isConfigurable: true/false
• configurableOptions is not accessible on rule instances in the UMD build
• Consumers must hardcode which rules accept expression vs threshold and their defaults

Expected behavior

• getRules() returns rule instances where configurableOptions is preserved and accessible
• Each ConfigurableOption includes name, type, description, and defaultValue
• This allows consumers to dynamically build configuration UIs without hardcoding rule-specific knowledge

Example of what consumers could do

const rules = lightningflowscanner.getRules();
for (const rule of rules) {
  if (rule.isConfigurable && rule.configurableOptions) {
    for (const opt of rule.configurableOptions) {
      console.log(`${rule.name}: ${opt.name} (${opt.type}), default: ${opt.defaultValue}`);
      // APIVersion: expression (expression), default: ">= 50"
      // CyclomaticComplexity: threshold (number), default: 25
      // FlowName: expression (expression), default: "[A-Za-z0-9]+_[A-Za-z0-9]+"
    }
  }
}

Why this matters

• Eliminates manual maintenance for downstream consumers when new configurable rules are added
• The code already exists — ConfigurableOption, configurableOptions, and per-rule declarations are all in place
• Minimal effort — likely just a Vite/Rollup config change to prevent property mangling, or ensuring the property is enumerable

Additional context

• Current UMD version tested: 5.9.7
• Consumer: Salesforce Inspector Reloaded browser extension
• The extension currently works around this with a hardcoded flowScannerKnownConfigurableRules map