feat(integration): connect Logfire with a project key and an organization key

[nwm-54]

polylane integration connect had no Logfire flow while polylane integration catalog already lists Logfire as connectable, so picking it was a dead end. This adds a logfire type modeled on the Grafana flow, targeting the two-key connect body introduced by coreplanelabs/nominal#2507: a project API key (query scope, existing --api-key) and an organization API key (notification-channel scope, new --organization-api-key). Each prompt quotes the literal Logfire dashboard labels for its key path; both values are trimmed and a missing one is a usage error that names the flag. Region is left to the API, which reads it from the key prefix.

Depends on nominal#2507 being deployed to production. The generated ConnectBody type comes from the live api.polylane.com/v1/doc spec, whose Logfire variant does not carry organizationApiKey yet, so npm run typecheck fails on this branch until that deploy lands. That failure is intentional: the API redacts both Logfire keys from the connect response, so unlike the Honeycomb management-key spread there is no way to detect an older API silently dropping the organization key, and a loud typecheck is the safer contract. Draft until the API deploy; then mark ready.

Verification, with codegen pointed at the production spec patched to #2507's Logfire schema (served locally):

• tsc --noEmit clean, npm run lint clean, npm test 460/460.
• integration connect --help lists logfire, the new flag, and the example.
• --type logfire --non-interactive exits 2 with Missing required flag: --api-key; with --api-key only, exits 2 naming --organization-api-key.
• npm run build and dist/polylane.mjs integration connect --help show the Logfire lines.

Not exercised: a live connect against an API that has #2507, which needs real Logfire keys.

🤖 Generated with Claude Code

[coreplane-switchboard]

LGTM: Clean Logfire connect flow modeled on Grafana/Honeycomb with good tests; only caveats are the declared dependency on nominal#2507 (typecheck red until deploy) and a flag-worded error reachable from the interactive prompt path.

• [minor] F1 src/commands/integration/connect.ts:1055 — Branch depends on unmerged/undeployed nominal#2507 — typecheck fails until the API deploy lands (declared; keep draft until then)
• [nit] F2 src/commands/integration/connect.ts:633 — Interactive whitespace-only paste surfaces 'Missing required flag: --api-key' after the wizard instead of re-prompting

Verdict: approve — a well-scoped, well-tested addition of the Logfire connect flow; two non-blocking notes below. (Reviewed head 1aace82, all 3 files / +131−7 covered.)

What the change does: adds logfire to ConnectableType and the observability picker, two secretStep prompts (project key + new --organization-api-key flag for the org key), an exported logfireKeyFields helper that trims both values and turns a missing one into a usage error naming the right flag, plus help-text/example updates and dedicated tests.

What I checked:

• Correctness — the flow mirrors the Grafana/Honeycomb patterns exactly. Non-interactive without a flag fails loudly inside secretStep (Missing required flag: <flag>, exit 2); an empty flag value falls through to logfireKeyFields, which names the specific missing flag with the pair hint. "Both missing → --api-key reported first" matches the test. BACK navigation composes correctly with runSteps (backing out of the first step returns to type selection).
• Tests — test/integration-connect-logfire.test.ts covers both-present, trimming, each-missing (including whitespace-only), both-missing ordering, and category placement/exclusion; the count assertions in the category test were updated consistently (16→17, observability 7→8).
• Consistency — the --api-key description, command description, and examples were all updated; logfireKeyFields is a small, justified sibling of the Honeycomb management-key pair check rather than gratuitous duplication, and the trimming rationale is documented.

Findings:

• F1 (minor) src/commands/integration/connect.ts:1055 — FYI/declared: the body = { type: 'logfire', ... organizationApiKey } shape depends on nominal#2507 being deployed; the generated ConnectBody from the live spec doesn't carry organizationApiKey yet, so tsc --noEmit is red on this branch. The PR body explains this is intentional (a loud typecheck beats an older API silently dropping the org key, since the connect response redacts both keys and offers no runtime detection). Reasonable trade-off — just keep it draft until the API deploy lands, as planned.
• F2 (nit) src/commands/integration/connect.ts:633 — in an interactive run, pasting a whitespace-only value at either prompt sails through secretStep and then aborts the completed wizard with Missing required flag: --api-key — flag-worded phrasing for a user who never used flags, and no chance to re-paste. The Honeycomb pair check has the same shape, so this is consistent with the codebase; a per-prompt non-empty validation would be the nicer fix if you ever touch this area again.

No docs/reference/specs/ in this repo, so no spec-contradiction check applies. The verification story in the PR body (codegen against the patched spec, 460/460 tests, help/exit-code checks) is thorough and matches what the code shows.

[github-actions]

Auto-approved: coreplane-switchboard[bot] reviewed this PR and posted an LGTM verdict (see its review). A repo admin enabled this via the auto-approve workflow.