Resolved with workaround
After a bunch of time on the phone with Ray (thanks, Ray!), it turns out that the problem is due to an assumption made by WebAssist extensions about file pathnames on Mac OS X. A simple but ugly workaround made it work for now.
If anyone else runs into this on Mac OS X (eyes-glazing-over content follows):
User preferences, and the per-user configuration for Adobe CS and extensions, is stored in the user's home folder/directory under Library/Application Support/Adobe. User home directories are usually found in /Users/{username}, e.g. "/Users/eric". Normally, this is fine, and normally WebAssist extensions seem to understand this.
If the user is using FileVault encryption on the home folder, then the user's home directory (and everything underneath) is actually in an encrypted filesystem which is mounted (Unix style filesystem mount) on top of the /User/{username} directory. Programs which expect the user's home directory to be in that location work just fine.
HOWEVER, the WebAssist library seems to go out of its way to discover that the user's home directory is not on the startup volume. Most of the time other volumes are mounted in the /Volumes directory. WebAssist seems to assume that this is the case. But for FileVault mounted home directories, the mount point is *not* /Volumes/{username} as WebAssist assumes, but is /Users/{username} as usual. So the special handling is incorrect. The normal /Users/{username} should be used.
The workaround: in a Terminal window make a symbolic link as follows:
sudo ln -s /Users/{username} /Volumes/{username}
The bummer is that /Volumes seems to get cleaned out on every reboot. So you get to do this again and again. It needs to be done as root (hence the "sudo") so you can't put it in a login item.
