generallegal 0.2.0: agent signup, four platforms

[Alexgodoroja]

Updates io.pilot.generallegal from 0.1.0 to 0.2.0.

Why

General Legal now exposes programmatic agent signup and key recovery (documented in their OpenAPI at api.general.legal/api/v1/openapi.json):

• POST /api/v1/signup: company, contact email, US billing address. Emails a six-digit code.
• POST /api/v1/signup/complete: code plus engagement_letter_accepted: true. Returns one API key, shown once.
• GET /api/v1/terms/agent-signup, POST /api/v1/signup/resend, POST /api/v1/api-key-recovery[/complete]

Under 0.1.0, contract review needed a human to sign up in the portal, copy a key into secrets.json and restart the app. That step is gone.

0.1.0 also shipped linux/amd64 only. Its catalogue entry has no bundles map and no metadata_url, so the app never spawns on macOS or arm64, and the metadata API returns app_not_found for it.

What changes

• New methods:
  • signup_terms, signup, signup_resend, signup_complete
  • key_recover, key_recover_complete
  • set_key
  • All are public routes or local.
• Saving the key: signup_complete and key_recover_complete use http.save_key. The key is cached in $APP/secrets.json, redacted from the reply and read per request, so there is no restart. set_key overwrites it with a portal key.
• Before signup: key-requiring methods soft-fail with a needs_signup hint instead of a raw 401. Formation methods are unchanged and still need no account.
• Grant: adds fs.write $APP/secrets.json. Network grants are unchanged (api.general.legal, incorp-mcp.general.legal).
• Bundles: signed with the original publisher key (ed25519:Tl5OtWqZ…I3lE=) for linux/amd64, linux/arm64, darwin/arm64 and darwin/amd64, with a bundles map in submission.json. publish-on-merge therefore releases all four and writes a full catalogue entry.
• Listing: metadata.json is regenerated (signup flow, vendor name, changelog). The product demo and next-steps graph now walk the signup flow (28 edges).

Verification

• pilot-app verify passes on all four bundles. pilot-app verify-update passes (same key, 0.2.0 ≥ 0.1.0).
• Next-steps graph validates against the 26 exposed methods. demo-score is 83.
• go vet ./... and go test ./... pass.
• Runtime: each platform's binary was run in socket mode and called against the live General Legal API:
  • linux/amd64 and linux/arm64 in containers
  • darwin/arm64 natively, darwin/amd64 under Rosetta
• Live calls:
  • The key gate returns the hint.
  • signup_terms returns the engagement letter URL.
  • signup and signup_complete reach General Legal's own validation without a key.
  • formation_options works.
  • set_key writes secrets.json with mode 0600, and the next call sends the key without a restart.
• Mock backend: signup → signup_complete → key saved and redacted → deals_list sends Bearer <minted key>.

Not covered

• No real signup: it emails a real address and engages a law firm. The first real account should be opened by someone with a company email right after release.
• "When available": General Legal's docs still label signup "when available". The endpoints are live and validating, but confirm general availability with them before announcing.
• Generator follow-ups (not in this PR):
  • Multipart routes aren't wrapped in requireKey, so document_upload with no key returns a raw 401.
  • A set_key url: adds a net.dial grant for a host the adapter never dials.