fix: various cross-namespace guide fixes

Remove an old TODO.

Fix path type.

Fix namespace template for consumer include.

app/_src/kubernetes-ingress-controller/plugins/cross-namespace.md

@@ -88,10 +88,11 @@ metadata:
 spec:
   parentRefs:
   - name: kong
+    namespace: default
   rules:
   - matches:
     - path:
-        type: Exact
+        type: PathPrefix
         value: /bintang
     backendRefs:
     - name: httpbin
@@ -171,15 +172,12 @@ secret/rustem-basic-auth created
 
 Create a consumers named `aygerim` and `rustem` that use these credentials:
 
+> TODO Something weird is happening here with the markdown rendering of the included code blocks.
+
 {% include /md/kic/consumer.md release=page.release name='aygerim' credName='aygerim-basic-auth' namespace='qyzylorda' %}
 
 {% include /md/kic/consumer.md release=page.release name='rustem' credName='rustem-basic-auth' namespace='qyzylorda' %}
 
-> TODO the addition of namespace here doesn't appear to be taking, and also
-> something horrible is happening between the import and markdown handling,
-> where the imported code blocks and prose are all being wrapped in code blocks
-> for the final render. Import caching maybe screwy?
-
 ## Grant cross-namespace permissions
 
 Luka and Kim wants to limit the amount of requests to the `httpbin` Service on
@@ -261,25 +259,6 @@ kongplugin.configuration.konghq.com/rate-limit-rustem created
 
 ## Attach the plugins to their resources
 
-> TODO we probably have a bit of a pickle here: you can't have two of the same
-> type of plugin attached to a given resource, and you can't create the
-> associations in a single apply because they need to be applied by different
-> users. The order of events here is thus quite persnickety:
-> - If you attach the plugins to the consumers first, as this does, it will
->   apply to _all_ their requests initially, not just those to the
->   `kualalumpur/httpbin` Service.
-> - If you reverse the order, and apply the annotations to the Service first,
->   you'll be attempting to apply two of the same kind of plugin to a single
->   resource, which is invalid. This will either cause a lock-up or trigger an
->   admission webhook block (IIRC we have a check that tries to see if you've
->   requested multiple of the same plugin) because we want to pretend that
->   eventual consistency isn't a property of Kubernetes by design :facepalm:
->
-> You can maybe dance around this by annotating first and creating the plugins
-> after (the missing plugins will be ignored AFAIK), but the level of knowledge
-> you need to not trigger badness is obscene and rather unintuitive. Hurray
-> conflicting models!
-
 {:.note}
 > In practice, you would likely not manually apply plugin configuration first
 > to the KongConsumers and second to the Services while they are live, as doing