docs: add FDC3 v3 web guidance for route-scoped identity, context-only apps, and private context types

website/docs/api/ref/GetAgent.md

@@ -157,6 +157,12 @@ As web applications can navigate to or be navigated by users to different URLs a
 
 Finally, if there is still no Desktop Agent available, or an issue prevents connection to it, the `getAgent()` function will reject its promise with a message from the [`AgentError`](./Errors#agenterror) enumeration.
 
+::: note 
+
+When several FDC3-enabled applications are hosted on the same origin (e.g. `https://myplatform.example.com/trade` and `https://myplatform.example.com/watchlist`), each should be registered as a separate AppD record using a URL that includes the distinguishing path.  
+
+:::
+
 ## Injected iframes for adaptors and user interfaces
 
 The `getAgent()` function may try to create hidden iframes within an application window in order to load either an adaptor to a Desktop Agent, or Intent Resolver and Channel Selector user interfaces when needed. The iframes are used in order to sandbox the relevant software, and are communicated with securely via the HTML Standard's Channel Messaging API ([MDN](https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API), [HTML Living Standard](https://html.spec.whatwg.org/multipage/web-messaging.html)).

website/docs/app-directory/overview.md

@@ -97,10 +97,16 @@ The AppD API specification defines the optional use of an access token to identi
 
 The specification does not define or make mandatory any authorizations or roles that a provider or enterprise can define.
 
-A key concept in the App Directory is how applications are identified and referenced across different environments. Application identifiers are used both to uniquely describe apps within a directory and, in some cases, to locate the directory instance that hosts an application’s record.
+## Application `interop` Metadata
+
+AppD records include an optional `interop` field that describes how the application uses FDC3 APIs. This metadata serves multiple purposes: it supports intent resolution by declaring what intents the app listens for (`interop.intents.listensFor`) and raises (`interop.intents.raises`); it enables app catalog UIs to surface apps that interoperate with a given application; and it documents the app's interactions with User Channels (`interop.userChannels`) and App Channels (`interop.appChannels`) for other developers and desktop assemblers. See the [App Directory specification](pathname:///schemas/next/app-directory.html) (or the raw [OpenAPI schema](https://fdc3.finos.org/schemas/next/appd.schema.json)) for the full definition of the `interop` field.
+
+Applications only need to complete the elements of the `interop` element that they make use of.  An app that only listens to context on a user channel need only complete this section, for example.
 
 ## Application Identifiers
 
+A key concept in the App Directory is how applications are identified and referenced across different environments. Application identifiers are used both to uniquely describe apps within a directory and, in some cases, to locate the directory instance that hosts an application's record.
+
 Application Records served by an app directory are each labelled with an identifier, `appId`, which should be unique within the app directory instance and may be used to refer to or retrieve the application's record via the [app directory API](spec). This identifier may be made globally unique through a nested namespace approach and email address construction (`appId@fqdn`) where `@` followed by the app directory instance's host name is appended to it. The resulting globally unique identifier is known as a 'fully qualified application identifier'.
 
 Fully qualified appIds may be used to locate the appD instance hosting the application's record. See the [Service Discovery](#service-discovery) section for details.

website/docs/context/spec.md

@@ -115,6 +115,20 @@ organization-specific namespace, e.g. `blackrock.fund`.
 
 All well-known types at FDC3 level are prefixed with `fdc3`. For private type definitions, or type definitions issued by other organizations, different namespaces MUST be used, e.g. `blackrock.fund`, etc.
 
+#### Private and Proprietary Context Types
+
+Organizations frequently need to share domain-specific data that is not (yet) covered by a standardized FDC3 context type. FDC3 explicitly supports this through the use of organization-specific namespaces.
+
+Private context type names MUST be prefixed with a namespace that is unique to the issuing organization. Using a reverse-domain convention (e.g. `com.example`) or a well-known organizational abbreviation (e.g. `acme`) avoids collisions with both FDC3-defined types and types created by other organizations:
+
+```
+com.example.account       ✔  reverse-domain namespace
+acme.rfq                  ✔  organizational abbreviation
+account                   ✗  no namespace — risks collision with future standard types
+fdc3.account              ✗  reserved for FDC3 standard types
+```
+
+
 ### `name`
 
 Context data objects may include an optional name property that can be used for more information, or display purposes. Some