Update baseline; change caused by HTTP file ID caching.

Seems reasonable for the situation -- there's gaps in HTTP client
content and the script-layer logic for determining file IDs used to
return different file IDs for two of the file gap events, but now the
internal mime entity is just re-using a previous file ID.  Seems fine to
me -- the script-layer tracking in the presence of entirely missed
requests or responses is going to be off so we can't expect the file IDs
returned based upon that state to be the right view of things.