Declare the guest grants that already shipped

Inverting the grantable rule from the .view suffix to explicit declaration
dropped every permission that had qualified by how it was spelled. Two of
them were shipped guest features with grants already in the field.

guides.view: the nav item and list_guides both reason in comments about a
signed-out reader holding it, and the route is written around one - drafts
are filtered out, search matches the published revision so draft wording
cannot leak through a hit, and the author branches cannot open for a caller
with no user id.

tools.view: without it a guest holding tools.secrets has permission to use
Secure Send and no way to reach the page, because tools.view is what puts
the entry in the nav. The tools themselves run in the browser and touch no
data.

The failure was worse than a missing checkbox. update_role refuses the
WHOLE request when any submitted permission is undeclared, and the role
grid resubmits what the role already holds, so a site that granted either
of these under the old rule could no longer save the guest role at all -
including to tick assets.view, which is the grant the shop floor needs to
look up an asset number without signing in.

The test asserts both stay grantable, so narrowing the set again means
looking at what is already granted in the field rather than only at what
the catalogue declares.

Scope: product

tests/test_core/test_guest_role.py

@@ -125,6 +125,28 @@ def test_a_view_permission_is_not_grantable_merely_for_being_a_view(app):
         assert name not in grantable, name
 
 
+def test_the_guest_features_that_already_shipped_stay_grantable(app):
+    """Both were granted on a live site before a grant had to be declared.
+
+    Inverting the rule to explicit declaration dropped every permission that
+    had qualified by its .view suffix, including two the product ships guest
+    flows for: guides, whose nav item and list route both reason about a
+    signed-out reader, and the tools page, without which a guest holding
+    tools.secrets cannot reach Secure Send at all.
+
+    A site that granted them under the old rule was then unable to save the
+    guest role AT ALL - the API refuses the whole request when any submitted
+    permission is undeclared, and the grid resubmits what the role already
+    holds. That deadlock is what this guards against, so anyone narrowing the
+    grantable set again has to look at what is already granted in the field.
+    """
+    from shopdb.core.models import guest_grantable_permissions
+    with app.app_context():
+        grantable = guest_grantable_permissions()
+    assert 'guides.view' in grantable
+    assert 'tools.view' in grantable
+
+
 def test_the_bytes_behind_applications_are_not_grantable(app):
     """applications.view is grantable only because the bytes moved off it."""
     from shopdb.core.models import guest_grantable_permissions
@@ -232,3 +254,4 @@ def test_a_bad_token_is_still_refused(client, db, guestrole):
     response = client.get('/api/auditlogs',
                           headers={'Authorization': 'Bearer not.a.token'})
     assert response.status_code == 422
+