Add unauthenticated legalTerms gql query

[GregorShear]

This PR:

• consolidates tenant creation and legal consent - two separate directives - into a single gql mutation
• requires legal consent only from the tenant's first user - new users who join an existing tenant will no longer be asked to agree
• stores versioned legal text as markdown in an append-only DB table internal.legal_term. Updated terms are inserted with a version bump to support some future mechanism of prompting an authorized user to agree to new terms
• consent is stored in a dedicated table internal.tenant_consent - this is the record that lives on if a users asks for their data to be deleted.

Legal terms are made available in an unauthenticated GQL query:

query {
  legalTerms(type: MSA) {
    text
    id
  }
}

and user consent rides along with the tenant creation mutation:

mutation {
  tenantCreate(
    name: "acmeCo"
    submittingUserAgreesToTermsId: "<latest MSA terms ID>"
    survey: { origin: "LinkedIn" }
  )
}

The resolver confirms the terms_id is the most recent version, and then inserts a row into internal.tenant_consent when creating the tenant.

[strix-security]

Strix Security Review

Warning

This pull request has 3 commits after the last Strix review (d1f49e9). Strix has not reviewed these changes.
Automatic review on push is off for this repository. To review the latest changes, tag @strix-security in a comment, or turn on re-review on push.

No security issues found.

Review summary

Reviewed the addition of an unauthenticated legalTerms GraphQL query. The resolver binds a sealed LegalTermsType enum into a parameterized sqlx query against a new immutable internal.legal_terms table, returning only publicly-available legal document text and a generated flow ID. No injection, authorization, secret-exposure, SSRF, IDOR, or deserialization issue was found. The migrations include appropriate integrity controls (unique (type, version), immutable updates). The version-assignment trigger's non-locking max+1 is a minor data-integrity race reachable only by internal operators, not the public API, and does not constitute a security vulnerability.

_{Updated for d1f49e9.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[skord]

Hey Greg, some notes from a legal/compliance angle:

• Not append-only yet. The trigger blocks UPDATE, but DELETE and TRUNCATE still work on legal_terms. Can you add guards for both?
• tenant_consent has no protection. Rows can be updated or deleted. It needs the same append-only guards.
• Consent doesn't survive user deletion. The FKs to auth.users and tenants don't have on delete set null, so deleting the user or tenant fails. Per the #product thread, the consent record needs no dependency on either row. Either add on delete set null or drop the FKs.