Declare AdminUI inner classes non-serializable (CodeQL java/non-serializable-inner-class)

[vharseko]

Summary

Resolves both java/non-serializable-inner-class alerts in AdminUI:

Inner class	Serializable via	Enclosing
AdminUI.AdminAction (line 864)	javax.swing.AbstractAction	AdminUI (not serializable)
AdminUI.SplashWindow (line 1320)	javax.swing.JWindow	AdminUI (not serializable)

Both are non-static inner classes that inherit Serializable from their Swing
superclasses, so each holds an implicit reference to its AdminUI instance. Since
AdminUI is not serializable, serializing either class already fails at runtime
with NotSerializableException on the outer instance.

Fix

Add readObject/writeObject to both classes that throw
NotSerializableException — the remediation the rule message itself proposes
("… or implementing readObject() and writeObject()"). This declares the classes
explicitly non-serializable instead of leaving the hazard implicit.

Behaviour is unchanged: serialization of either class already threw
NotSerializableException (via the un-serializable outer reference), and these are
internal Swing helpers that are never serialized in the application.

Why not static

Both classes use the enclosing AdminUI instance — AdminAction reads
_refreshing / _refreshOnceButton and calls getProperty / createAction;
SplashWindow clears AdminUI._splashWindow when dismissed. Converting them to
static would mean threading an explicit owner reference through every
construction site, a larger and riskier change in this untested Swing UI. The
readObject/writeObject route is minimal and behaviour-identical.

Note

AdminUI.java is also touched by #239 (thread-start-in-constructor), but in a
different region (the constructor / main); this change only appends methods at
the end of the two inner classes, so the two should merge cleanly apart from the
shared copyright-header line.

Testing

mvn -o -pl persistit/ui compile — BUILD SUCCESS.