P1 Front: create/link issues from conversations and reopen on resolution

[jaeyunha]

Parent: #556

Problem

Front is part of Linear’s customer-feedback/support integration story. Exponential has a customer request parent (#556) but no provider-specific integration for Front.

Evidence

• Parent Parity: add Customer Requests data model, customer pages, and issue/project linking #556.
• Linear Front docs: https://linear.app/docs/front

Scope

• Implement Front app/sidebar flow, create/link issue from conversation, Linear backlink attachments, reopen conversation when issue is done/canceled.
• Map external users/accounts to Exponential customers and customer requests.
• Store external source links and immutable provider metadata.
• Add admin setup, reconnect, and disconnect flows.
• Respect privacy/private-team boundaries and provider permission failures.

Acceptance Criteria

• Admin can connect Front.
• A provider record can create or link to an Exponential issue/customer request.
• Linked issue status is visible back in Front where the provider supports it.
• Closing/completing an issue triggers the documented provider-side follow-up where supported.
• Disconnect preserves historical source links but stops sync.

Validation

• make check
• make test
• Provider-specific Go tests with signed webhook/OAuth fixtures where applicable
• Playwright E2E for admin setup and the user-visible workflow
• OpenAPI and SDK regenerated when API contracts change

[jaeyunha]

Spec-prep result:

• Contract:
  • Add front to the integration catalog/OpenAPI/SDK and settings lifecycle, reusing workspace_integration, provider_credential, provider_job, and provider_event; admin setup supports install/connect, reconnect, and disconnect.
  • Build Front app/sidebar endpoints for authenticated Front users to search Exponential issues, create an issue from a Front conversation, link/unlink existing issues, and return issue identifier/title/status/assignee/permalink to Front.
  • Persist each Front conversation/message/contact/account link as provider source metadata and an Exponential issue/customer request association; depend on Parity: add Customer Requests data model, customer pages, and issue/project linking #556 customer/customer_request entities and do not create a parallel customer model.
  • Queue outbound Front updates when a linked issue is completed or canceled: post an internal note and reopen the conversation where Front permissions/inbox privacy allow it; permission/private-team failures record provider health events without leaking restricted issue data.
• Acceptance checks:
  • Admin connect/reconnect/disconnect works from settings; disconnect revokes credentials/cancels future jobs while preserving historical source links.
  • Front fixture flow can create a new issue and link an existing issue from a conversation, with idempotent duplicate link handling and visible current issue status back in Front.
  • Customer/contact/account mapping creates or reuses customer and customer_request records from Parity: add Customer Requests data model, customer pages, and issue/project linking #556 without overwriting immutable provider metadata.
  • Signed/OAuth fixture Go tests cover callbacks/webhooks, create/link/unlink, close/cancel reopen jobs, and private/permission failure paths; OpenAPI/SDK are regenerated.
  • Web unit tests and Playwright cover admin setup plus the user-visible Front sidebar workflow.
• Human question: none