Note: this issue is pretty blocking for the {{#get}}

At the moment, the Posts Browse endpoint supports a property called staticPages. If set to true, this includes any posts which have page: true set on them (pages). Perfect for the admin UI! However, it's not great as a general API feature. There is currently no way to fetch just pages... which is weird, and the staticPages parameter is horribly named.

The ideal thing here, I think, is to pass do api.post.browse({page: true}) as that matches the name of the property in the database. We should also support api.post.browse({page: null/all}) (so that the possible values are true, false or either null or all, depending on what makes sense) so that we can still support returning both for the time being.

In addition, it would be best to create an alias of page for posts with page=true, at least in the helper itself, so that you can do {{#get 'pages'}} instead of {{#get 'posts' page="true"}}.

The blocker for doing this is #5093, because page in the API currently refers to pagination, rather than the page property. If we use offset directly, instead of page for pagination in the API, not only do we get a more flexible interface, but we also get the page keyword back for use for actual pages!

Two other possibilities would be

1. to have api.post.browse({isPage: true}) in which case we'd probably want consistency in api.post.browse({isFeatured: true}) - not sure about this.
2. to have api.post.browse({postOrPage: page}) - I'm very wary of anything generic like type because that just spreads the idea there might be more options like this in future.

In the long run, pages and featured might get reimplemented as hidden/private tags instead of properties on the post model itself, so I think keeping the most simple interface (page:true) is best?