* Fix coll permissions for audit collection

We've had a function in `models.collection` for a while that has taken a
permissions set and returned a set of collection IDs that the user has
permissions on. I refactored this recently, but didn't notice that it
was actually doing the permissions checks slightly incorrectly.
Specifically, because it only looks at the user's permissions and the
collection IDs and doesn't use `mi/can-read?` or `mi/can-write?`, it's
completely indifferent to whether a collection is an audit collection or
not.

This is arguably not a *permissions* issue: the two errors that could
come about here are:

- someone sees the audit collection even though the audit feature is
disabled, or

- someone is presented with the audit collection in a context where only
writable collections should be present - when they try to actually write
to it, it fails (since then we're doing the real permissions check).

The primary motivation for this fix was to prevent audit dashboards and
cards from appearing in the list of stale items.

* Fix hardcoded collection ID

We were creating a timeline in a fixed collection ID, that in tests
happened to be the ID of the Metabase Analytics collection.