Sorry... I had intended to reply, I must have got distracted or something...
Just to recap, the first two values should represent the square of the magnitude of the DC output of the short-time Fourier transform, and that of the first non-DC bin (perhaps with some factor depending on the windowing). The DC (0Hz) bin just reflects whether the balance of the signal is positive or negative during the analysis period, and its square is not necessarily going to be useful or related to the rest of the spectrum. The next bin is the lowest separable frequency component (e.g. 43Hz approx in a 1024-point FFT).
Running this plugin myself, the results do look OK. There is not supposed to be any feedback from one processing block to the next such as might cause a value to keep increasing in the absence of any input. My first response to the sort of small values you're seeing would be to suggest soundcard converter noise, but a bug is possible (I just haven't seen it yet).
You're using ADAPT_ALL_SAFE when loading the plugin, which means the host SDK is going to do the FFT for you. Does it make any difference whether you build the host SDK with FFTW support or the built-in FFT? (It shouldn't, but it's worth a try.) The option for this is somewhat hidden; I don't especially want distributors using it because it changes the effective license of the SDK, but if you read near the top of src/vamp-hostsdk/PluginInputDomainAdapter.cpp you'll see that adding -DHAVE_FFTW3 to the Makefile should be enough to build it with FFTW instead of the built-in FFT. (It will run faster then, too.)