Support custom domains for individual tags

このissueでは、関連するエントリーポイントとして、backend agent/plugin routerの境界、frontend route plugins、tag administration UI/API、core routerが特定されています。まず、Hostリクエストがどのようにtemplate/UI routesへ到達するのか、またtag lifecycleとadministrator configurationがどのように表現されているのかを追跡してください。完了とするには、routing modelを決定し、validation、permissions、navigation、authentication、およびtag lifecycle changesの動作を定義する必要があります。

Is your feature request related to a problem? Please describe

An Answer instance can contain multiple topic communities, but every tag is currently accessed under the single site domain, for example community.example.com/tags/golang.

Some operators want topic-specific entry points while keeping one Answer deployment, user base, database, and administration surface. For example:

• golang.example.com opens the golang tag landing page.
• kubernetes.example.com opens the kubernetes tag landing page.
• A branded campaign or partner domain opens the tag that represents that community.

This avoids operating a separate Answer instance for every topic and makes focused communities easier to share and brand.

The current plugin mechanism cannot implement this end to end. Backend agent plugins can register handlers only inside the existing API router groups, while frontend route plugins add client-side application routes. Neither can inspect the top-level request Host before the UI/template router nor map that Host to a tag landing page.

Describe the solution you'd like

Support an optional custom domain binding for a tag. When a request reaches the root of a bound domain, Answer should resolve the mapping and open the corresponding tag landing page.

Expected properties:

• A domain can be bound to at most one active tag.
• Domain values are normalized and validated; schemes and paths are not part of the stored mapping.
• Existing /tags/{slug} URLs and deployments without bindings continue to work unchanged.
• Domain configuration is restricted to administrators.
• DNS and TLS certificate provisioning remain the operator's responsibility.
• Behavior is defined for deleted, renamed, merged, or synonymous tags.

There are two possible implementation directions.

Option 1: Add a plugin extension point

Add a server-level plugin hook that runs before the template/UI routes and can match the request Host, then rewrite or redirect the request to a target application route. A plugin could use its existing configuration UI, including the tag selector field, to maintain domain-to-tag mappings.

Advantages:

• Keeps custom-domain behavior outside the core tag model.
• Creates a reusable extension point for other host-based experiences, such as tenant portals or campaign entry pages.
• Allows different deployments to choose redirect, rewrite, or other policies.

Costs and risks:

• Introduces a security-sensitive routing API with ordering, failure-isolation, caching, and Host-header validation requirements.
• The hook must interact correctly with private mode, authentication, static assets, API routes, and configured base paths.
• The plugin contract would need a stable way to resolve tag metadata and react to tag rename/delete/merge events.
• A broad extension point may be larger and harder to maintain than this specific feature requires.

Option 2: Add tag-domain binding as a built-in feature

Add a domain mapping to the tag model (or a dedicated mapping table), expose it in the tag administration UI/API, and resolve the request Host in the core router.

Advantages:

• Provides a discoverable, consistent administrator experience.
• Keeps validation, uniqueness, permissions, migrations, tag lifecycle, and routing behavior in one place.
• Has a smaller and more explicit behavior surface than a general Host-routing plugin API.

Costs and risks:

• Adds a deployment-specific concept to the core tag model.
• Is less reusable for non-tag Host-routing use cases.
• Core code must define navigation, authentication, canonical URL, and cache behavior across multiple domains.

Describe alternatives you've considered

• Configure a reverse proxy to redirect each domain to the primary site's /tags/{slug} URL. This requires no Answer change, but the custom domain disappears after the redirect and every operator must maintain the mapping externally.
• Configure a reverse proxy to rewrite the path while preserving the custom domain. This can display the landing page, but Answer is not aware of the alternate origin, so cookies, OAuth callbacks, CSRF/origin checks, canonical URLs, generated links, and navigation may be inconsistent.
• Run one Answer instance per topic. This provides complete isolation but duplicates infrastructure, users, administration, upgrades, and data.

Questions for maintainers

1. Should this be a general plugin extension point or a built-in tag feature?
2. Should a bound domain remain visible and serve the tag page, or should it redirect to the primary site's /tags/{slug} URL?
3. If the custom domain remains visible, should only its root represent the tag, or should all navigation continue on that domain?
4. Should unrelated domains be supported, or only subdomains that can share authentication cookies with the primary site?
5. What should happen to a binding when a tag is renamed, merged, converted to a synonym, or deleted?