Adding a config-backed {appUrl} token for notify subject/body interpolation

[TIVMOF]

Problem

The notify block (shared by notifications[], schedules[].notify, transitions[].notify, and a
serviceTask's args.notify) interpolates {field} / {relation.field} placeholders in
subject:/body:, but has no concept of the application's own external base URL. An author writing
{appUrl} to link back to the record (e.g. "you have an approval waiting") got no error — the
resolver silently treated the bare word as an entity field, PascalCased it, and emitted
entity.AppUrl into the generated Java, which doesn't exist on any entity and fails javac for the
whole client-Java batch the moment the project is generated and published.

Fix

{appUrl} is now a reserved, config-backed token instead of falling through to the "must be a real
entity field" assumption:

• DirigibleConfig.APP_BASE_URL — new entry, env var DIRIGIBLE_APP_BASE_URL, default "".
• TenantConfigurationKeyPolicy — added DIRIGIBLE_APP_BASE_URL to the explicit tenant-override
  allow-list.
• NotificationSupport.Resolver.access() — special-cases the literal token appUrl before the
  direct-field branch, resolving it to
  org.eclipse.dirigible.sdk.core.Configurations.get("DIRIGIBLE_APP_BASE_URL", "") instead of
  entity.AppUrl. Since this is the one shared resolver behind all four notify call sites, they all
  pick it up automatically — no template changes needed (they already import the Configurations
  facade for DIRIGIBLE_MAIL_SENDER).
• intent-assistant-guide.md — documented the token for the AI assistant: it supplies only the
  origin (https://app.example.com), never a full route — the intent layer stays path-agnostic, and
  the author appends the rest of the URL as plain text/other placeholders

Example — before vs. after

• "bodyExpression": "... + entity.AppUrl + "/orders/" + entity.Id" // entity.AppUrl doesn't exist -> javac failure

• "bodyExpression": "... + org.eclipse.dirigible.sdk.core.Configurations.get("DIRIGIBLE_APP_BASE_URL", "") + "/orders/" + entity.Id"

Known limitation (documented, not fixed here)

Tenant overrides of DIRIGIBLE_APP_BASE_URL won't yet take effect when read from inside a generated
notification listener. The tenant-config thread map is only populated by
TenantConfigurationInitFilter, an HTTP-request-only filter; a notification always fires from an
async MessageHandler (ListenerClassConsumer), which re-establishes the tenant's identity but
not its config overrides — confirmed the same gap exists in the JS-side
AsynchronousMessageListener. This is a pre-existing, platform-wide limitation affecting every
listener that reads any tenant-configurable key, not something introduced by this change. It falls
back correctly to the global env var / default in the meantime. Flagged in
NotificationSupport.APP_URL_TOKEN's javadoc for discoverability; fixing it (wiring
Configuration.setThreadConfiguration(...) into listener dispatch) is a separate, cross-cutting
follow-up.