feat: build the Obiente support portal and private intake

[veryCrunchy]

User problem

People using Obiente products need a straightforward place to report bugs, request features, and send diagnostic information. Requiring a GitHub account excludes users who do not know GitHub or do not want to use it, while publishing support details directly as GitHub issues can expose private information.

Outcome

Provide one support portal for every Obiente project. Users can submit a bug report, feature request, or general support request without a GitHub account. Obiente applications can send explicitly approved diagnostic reports to the same service.

The service is product-neutral. Products are selected from a maintained registry and use versioned integration contracts; no route, data model, or operator workflow may be hard-coded specifically for Nextcloud Native.

Public user experience

• Let the user choose an Obiente product and request type: bug, feature request, or general support.
• Do not require a GitHub account.
• Ask only for information relevant to the selected request type.
• Clearly distinguish information that may become public from private contact details and diagnostics.
• Allow an optional contact method. Explain that anonymous reports cannot receive a reply.
• Return a human-readable support code and a private status link after submission.
• Allow the submitter to add information or delete the report using an unguessable private capability.
• Meet keyboard, screen-reader, contrast, reduced-motion, responsive, and localization requirements.
• Provide an accessible abuse challenge only when risk requires it.

Application integration

• Publish a small versioned intake API that any Obiente application can integrate with.
• Accept product identity, release/platform metadata, the user's description, and an optional bounded diagnostic attachment according to that product's registered schema.
• Require explicit in-app review and confirmation before diagnostics are sent.
• Support streaming upload, progress, cancellation, idempotent retry, and ambiguous-result reconciliation.
• Return the same support code and private status capability used by web submissions.
• Never turn application diagnostics into telemetry or automatic crash submission.

Public tracker and GitHub bridge

• Provide a public, searchable view of maintainer-approved bugs and feature requests without requiring GitHub knowledge.
• Keep new submissions private until they pass moderation and privacy review.
• Never publish diagnostic archives, contact details, IP addresses, deletion capabilities, or unreviewed free text.
• Let authorized maintainers promote a sanitized request to the appropriate product's GitHub repository.
• Preserve a durable mapping between the support request and GitHub issue without exposing private intake data.
• Synchronize public title, status, resolution, and safe maintainer updates where appropriate.
• Make duplicates and related requests discoverable and allow maintainers to merge public demand counts without merging private identities.

Privacy and security

• Use HTTPS in transit and encryption at rest.
• Store reports under opaque high-entropy identifiers with no public or guessable object URLs.
• Apply strict size, type, schema, archive-entry, decompression, and content validation.
• Protect against path traversal, decompression bombs, executable uploads, replay, spam, and quota exhaustion.
• Minimize operational metadata and do not add advertising identifiers or stable device fingerprints.
• Separate public request data, private contact data, and diagnostic objects with least-privilege access.
• Audit maintainer access to private reports.
• Publish retention periods and automatically delete expired private data.
• Let users delete an active private report through their capability link.
• Keep secrets and private submissions out of application logs, GitHub Actions output, analytics, and error reporting.

Maintainer experience

• Authenticate maintainers through an Obiente-controlled identity provider with role-based product access.
• Provide queues for new, needs-information, accepted, duplicate, resolved, rejected, and abuse states.
• Preview exactly what would become public before creating or updating a GitHub issue.
• Search private reports only within authorized product scope.
• Show retention deadlines and access history.
• Support safe export for incident response without producing public links.

Acceptance criteria

• A user can submit and track bugs, feature requests, and support requests for any registered Obiente product without GitHub.
• Product onboarding is configuration or contract driven and is covered by a second synthetic product fixture.
• Private submissions require moderation before any public listing or GitHub publication.
• Authorized promotion creates an issue in the configured product repository through a narrowly scoped GitHub integration.
• Diagnostic attachments remain private, bounded, validated, access-controlled, audited, and automatically expired.
• Status, duplicate, rejection, resolution, deletion, and optional-contact flows are complete.
• Web and application submissions return idempotent receipts and survive interrupted responses without duplication.
• Threat-model, privacy, accessibility, API-contract, retention, abuse, and backup/restore tests pass.
• Deployment and operator documentation describe recovery, key rotation, data deletion, and incident response.

Initial product integrations

• Nextcloud Native direct diagnostic submission