Open the record a search result found, not the list it sits in

A NOTICE result linked to /notifications, so clicking the row search had
already identified dropped the reader on the list page to find it again by
hand. The id was in the payload the whole time; only the URL ignored it.
`/notifications/<id>` is the existing notification-detail route.

The subnet searcher had the same defect two functions away: an IP search
resolves which subnet the address falls inside, then linked to /network, the
hub. It now links to /networks/<id>, the subnet detail route.

Every other search result type already carried its id. These were the only
two that did not.

shopdb/core/api/search.py

@@ -658,7 +658,10 @@ def _search_subnets(query):
                         'id': subnet.subnetid,
                         'title': f'{subnet.name} ({subnet.cidr})',
                         'subtitle': subnet.description or subnet.subnettype,
-                        'url': f'/network',
+                        # the matched subnet, not the hub: searching an IP
+                        # already identified WHICH subnet, so landing on the
+                        # hub makes the reader find it again by hand
+                        'url': f'/networks/{subnet.subnetid}',
                         'relevance': 70
                     })
             except ValueError:
@@ -779,7 +782,9 @@ def _search_notifications(query, search_term):
                 'id': notif.notificationid,
                 'title': notif.title,
                 'subtitle': notif.notificationtype.typename if notif.notificationtype else None,
-                'url': f'/notifications',
+                # the notification itself, not the list it sits in: the
+                # `notification-detail` route renders one by id
+                'url': f'/notifications/{notif.notificationid}',
                 'relevance': min(int(base_relevance), 100),
                 'ticketnumber': notif.ticketnumber,
                 'iscurrent': notif.is_current