Rethink authz around retrieving IP pools

Prior to #3985, there was a single fleet-level default IP pool named "default", and any authenticated user can CreateChild on a given IP pool:

https://github.com/oxidecomputer/omicron/blob/58e8c67e3449fe656a6d20721bbdab786034031e/nexus/db-queries/src/authz/omicron.polar#L387-L390

So when we looked up the default pool, we could rely cleanly on something like this to enforce permissions.

LookupPath::new(opctx, &self)
    .ip_pool_name("default")
    .fetch_for(authz::Action::CreateChild)

In #3985, there can be multiple default pools at different scopes (fleet, silo, or project), so figuring the default is more of a listing operation, which means we don't have a single pool up front to do an auth check on. One option is to do the query and then run the auth check on the resulting pool. But we will also want to do things like list available pools at a given scope in order to allow users to choose one at instance create time in the CLI or console. So I think this might call for a rework of the permission model around IP pools.

Start with the permission rules in nexus/db-queries/src/authz/omicron.polar around lines 387-390 and trace the LookupPath::ip_pool_name("default") call described in the issue. Compare this with the scoped default pools introduced by #3985 and the planned CLI or console listing flow. Done means the permission model clearly supports retrieving and listing eligible IP pools at fleet, silo, and project scopes.