Make sure that updated wallpaper id is immediate

As soon as setBitmap() or equivalent returns, the new wallpaper id needs
to be immediately observable.  This was being subverted by inconsistent
and racy "initialize from persisted state" handling in the set-wallpaper
case: a load triggered by rebinding the static image display service
could in some cases wind up overriding the new state calculated while
new wallpaper imagery was being processed.

The fix is to clarify the semantics of when load-from-persisted happens:
it is now done *only* when the user is first spun up (or at boot, for
the system user), and a firm guarantee provided about the up-front
availability of the associated bookkeeping.  That, in turn, means not
having to futz with lazy init when some client wants to read the current
wallpaper imagery, and eliminating that gets rid of the races.

And in a strictly-cosmetic fix, corrected the descriptive text for one
of the permission enforcement calls.  Copypasta strikes again!

Bug: 65016846
Test: cts-tradefed run cts-dev -m CtsAppTestCases -t android.app.cts.WallpaperManagerTest\#setBitmapTest
Change-Id: I73da48a58cca1849f073b8aea72019916dc2272b