Chromium clearData reports success without clearing anything

[NAME-ASHWANIYADAV]

What happens

RuntimeImpl.clearData() in the Chromium backend is a stub that reports success:

// app/src/common/chromium/.../impl/RuntimeImpl.java:82-85
public WResult<Void> clearData(long flags) {
    // TODO: Implement
    return WResult.fromValue(null);
}

WResult.fromValue() returns an already-completed result, so callers take their success path even though no data was touched. The Gecko backend really clears (gecko/RuntimeImpl.java:91-92 delegates to StorageController.clearData()).

The user-facing path: Settings -> Privacy has "clear cookies and site data" (PrivacyOptionsView.java:74-79) and "clear web content" (:81-83); both call SessionStore.clearCache(), which calls mRuntime.clearData():

// SessionStore.java:493-507
public void clearCache(long clearFlags) {
    for (Session session: mSessions) {
        if (session.getWSession() != null) {
            session.suspend();
            activeSession.add(session);
        }
    }
    mRuntime.clearData(clearFlags).then(aVoid -> {
        for (Session session: activeSession) {
            session.recreateSession();
        }
        return null;
    });
}

On Chromium every session is suspended and recreated, so pages visibly reload and the action looks like it worked - while cookies, site data and caches are untouched. A privacy control that silently does nothing is worse than one that is visibly unavailable.

A trap for anyone fixing this

The obvious interim fix - completing exceptionally, the way DisplayImpl.capturePixels was handled in #2025 - would regress this path. There is no .exceptionally() on the chain above, and recreateSession() for every suspended session lives inside the .then(). Failing the result would leave every session suspended and never recreated.

So an interim "fail honestly" fix has to change the caller too: recreate the sessions on the error path (or suspend only after a successful clear). The real fix is to implement clearData against Chromium's BrowsingDataRemover, mapping WRuntime.ClearFlags onto its data-type mask.

A PR with the interim fix (fail honestly, and make the caller recreate sessions on the error path too) accompanies this issue. The real BrowsingDataRemover implementation remains follow-up work.