feat(apps): disable Update App button when there are no changes (#3559)

[mdmohsin7]

Closes #3559.

What

Disable the Update App button on the Omi App Store "Update App" page until the user actually makes a change, and re-disable it if they revert everything.

How

AddAppProvider now tracks dirty state:

• prepareUpdate snapshots the loaded app into _originalApp and attaches change listeners to every text controller (so the button reacts as you type, including fields outside the metadata Form).
• checkValidity() recomputes hasChanges = hasDataChanged(_originalApp) on every field change.
• hasDataChanged was rewritten to compare all editable fields, order-insensitively: name, description, visibility, category, capabilities (by id), pricing (plan + price, only when paid), conversation/chat prompts, source-code URL, external-integration fields, proactive-notification scopes, thumbnails, and a newly-picked logo.

update_app.dart gates the button on isValid && hasChanges — onTap is null and the fill turns grey when there are no changes.

Acceptance criteria

• Disabled on initial load (no changes).
• Any edit to a field enables it.
• Reverting all fields back to original disables it again.
• Disabled state is visually clear (grey fill) and non-clickable.

Notes — why this isn't the earlier reverted attempt (#7975)

That PR was reverted because it broke the build: app.capabilities.map((c) => c.id) — app.capabilities is Set<String>, so String has no .id. Here capabilities are compared with setEquals(selectedCapabilities.map((c) => c.id).toSet(), app.capabilities.toSet()). It also would have falsely marked free apps dirty (priceController.text != "0.0" when the price field is empty) — fixed by only comparing price/plan when the app is paid.

Tests

test/providers/add_app_provider_test.dart — 10 cases covering the no-change baseline, each field's edit→dirty, revert→clean, the free-app empty-price regression, capability-by-id, and logo pick. All green via flutter test. Verified flutter pub get + dart analyze clean on the changed files (no new issues).

[cubic-dev-ai]

2 issues found across 3 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[mdmohsin7]

Both valid — fixed in 126cbcf (identified by cubic):

1. P1 (dirty state wiring): setIsPaid, setPaymentPlan, and setIsPrivate only called notifyListeners(), so toggling visibility/paid/plan left hasChanges stale. Added checkValidity() to all three (category, capability, and scope setters already had it; text fields are covered by controller listeners).
2. P2 (external-integration coverage): hasDataChanged now also compares the auth-step URL and the actions set (order-insensitive), so editing only those enables Update.

Added test coverage for the auth-URL and actions cases; full provider suite is green (13 tests).

[cubic-dev-ai]

1 issue found across 3 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[mdmohsin7]

Valid — fixed in the latest commit (identified by cubic). prepareUpdate assigned app.thumbnailUrls/thumbnailIds by reference, so the in-place add/removeAt in pickThumbnail/removeThumbnail mutated the _originalApp snapshot too, making setEquals always match. Now copying both lists with List.of(...), plus added checkValidity() after a thumbnail upload (removeThumbnail already had it). Added a thumbnail dirty-state test; suite green (14).

[cubic-dev-ai]

1 issue found across 3 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[mdmohsin7]

Fixed in the latest commit (identified by cubic). The external-integration block was gated on ext != null, so adding those fields to an app that had no integration wasn't detected — now compared null-safe. I also applied the same null-safe treatment to the proactive-notification scopes check, which had the identical gap, to head it off. Added a regression test (external field on a non-integration app). Suite green (15).

[cubic-dev-ai]

1 issue found across 3 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[mdmohsin7]

Fixed in the latest commit (identified by cubic). Root cause: the provider is reused across the add/update flows and prepareUpdate only seeds optional fields (integration/scopes/prompts) when the app has them; once the dirty check compares those unconditionally, stale leftover values read as a false change. Fix is systemic — prepareUpdate now calls clear() first so the baseline is always clean for every field (not just the ones flagged). Added a clear() regression test. Suite green (16).

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}