…nal configurability (#3110)

### Motivation
The conditional configurability V0 feature requires new condition types
in the data layer to support dynamic paywall component visibility based
on variables, packages, and extended intro/promo offer conditions.

### Description
- Adds `Variable`, `Package`, `SelectedPackage` data classes to
`ComponentOverride.Condition` sealed interface
- Extends `IntroOffer` and `PromoOffer` conditions from simple objects
to data classes with `operator` and `value` fields (backwards compatible
with legacy format)
- Adds `EqualityOperator`, `ArrayOperator`, and `ConditionValue` types
for condition evaluation
- Updates `ConditionSerializer` to handle new types with fallback to
`Unsupported` on parse errors
- Comprehensive unit tests for deserialization, backwards compatibility,
unknown types, and malformed data

**Tasks:** PW-169 (1.1–1.13)

Co-authored-by: Cursor <cursoragent@cursor.com>

… to trigger fallback paywall (#3113)

### Motivation
When a paywall uses condition types that this SDK version doesn't
understand (e.g., conditions added in a newer backend version), the SDK
should gracefully fall back to the default paywall rather than rendering
incorrectly.

### Description
- Adds `UnsupportedCondition` validation in `toPresentedOverrides`. If
any override contains an `Unsupported` condition, it produces a
`PaywallValidationError`
- Adds `PaywallValidationError.UnsupportedCondition` error type with
descriptive error string

---------

Co-authored-by: Cursor <cursoragent@cursor.com>

We were missing support for boolean and number custom variables

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Public API surface changes by making `CustomVariableValue.Number` and
`CustomVariableValue.Boolean` publicly constructible and updating call
sites to use typed values, which could affect downstream integrations
and string formatting expectations.
> 
> **Overview**
> Adds first-class support for numeric and boolean custom paywall
variables by making `CustomVariableValue.Number` and
`CustomVariableValue.Boolean` public and exporting them in the public
API (`api.txt`).
> 
> Updates the tester apps and examples to construct and pass typed
`Number`/`Boolean` values (instead of stringifying), including the
custom variables editor dialog’s value creation logic and sample
`CUSTOM_VARIABLES`/API tests.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
84aec0f. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Now that we know the JSON is not changing, adjusted the logic to be
simpler. Also found we can use `JSONPrimitive` and simplify things a
lot.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes core JSON deserialization/fallback behavior for paywall
components and override conditions; malformed payloads will now preserve
the declared `type`, which could alter fallback outcomes in edge cases.
> 
> **Overview**
> Simplifies component override variable conditions by replacing the
custom `ConditionValue` sealed type/serializer with a raw
`JsonPrimitive`, and updates variable-matching logic in
`PresentedPartial` to interpret strings/booleans/numbers directly.
> 
> Hardens `SealedDeserializerWithDefault` to handle non-object JSON and
to **preserve the discriminator `type`** when deserialization of a known
type fails (instead of losing it), with expanded tests covering
malformed known types, extra/unknown fields, and `null` variable values.
Also promotes `kotlinx-serialization-json` to a runtime dependency in
`revenuecatui` since `JsonPrimitive` parsing is now used in production
code.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
92e8e9a. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

…nditions (#3175)

When an unsupported condition is encountered, instead of falling back to
the generic fallback paywall, the SDK now renders the same components
paywall with only base condition overrides applied, stripping all
rule-based overrides.

Also renames `IntroOfferCondition`/`PromoOfferCondition` to
`IntroOfferRule`/`PromoOfferRule` and adds `Condition.isRule` to
distinguish rule conditions from base conditions.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Alters runtime paywall rendering/override selection when unknown
conditions are encountered, which may change UI behavior for some
configurations. Logic is well-covered by new traversal and
override-filtering tests, but impacts core presentation paths.
> 
> **Overview**
> **Unsupported condition handling is softened:** when any
`ComponentOverride.Condition.Unsupported` is detected anywhere in the
components tree, the SDK now renders the components paywall but *strips
all overrides that use rule-based conditions* (plus the unsupported
ones), leaving only base-condition overrides.
> 
> This introduces `Condition.isRule` and renames
`IntroOfferCondition`/`PromoOfferCondition` to
`IntroOfferRule`/`PromoOfferRule`, updates condition
evaluation/serialization accordingly, removes the `UnsupportedCondition`
validation error pathway, and adds a recursive
`containsUnsupportedCondition()` scan with expanded unit test coverage.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
ba8a4cb. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>