Fix company import label portability

[starlessrider]

Thinking Path

• Paperclip orchestrates AI agent companies through company-scoped agents, projects, issues, and reusable company packages.
• The company import/export subsystem should let operators move or duplicate a company package into a different company boundary.
• Issue labels are company-scoped database records, so raw label ids from the source company are not portable across imports.
• Export currently writes task labelIds directly, and import passes those ids to issue creation, which can fail with One or more labels are invalid for this company when importing into a new company.
• This pull request makes labels portable by exporting label definitions and task-level label slugs, then resolving or creating target-company labels on import.
• The benefit is that company packages with labelled tasks can round-trip into new companies without leaking source-company ids or failing validation.

What Changed

• Added portable label entries to the company portability manifest and validator.
• Export labels used by selected issues into .paperclip.yaml as label definitions.
• Export task label references as labelSlugs instead of raw source-company labelIds.
• Import portable labels by reusing target labels with the same name or creating them when absent.
• Keep legacy raw labelIds safe: preserve them only when they already exist in the target company, otherwise skip them with a warning instead of passing invalid ids into issue creation.
• Updated portability tests, CLI test fixtures, and import/export docs.

Verification

• pnpm test:run cli/src/__tests__/company.test.ts server/src/__tests__/company-portability.test.ts server/src/__tests__/company-portability-routes.test.ts
• pnpm typecheck

No UI surface changed; screenshots are not applicable.

Risks

• Low-to-moderate compatibility risk: this adds labels and labelSlugs to the portable manifest while retaining labelIds as legacy-compatible input.
• Existing packages with only raw labelIds cannot preserve labels when imported into a different company unless matching label ids already exist in the target; those labels are now skipped with a warning instead of failing the import.
• Existing target labels are matched by exact name; if a package expects a same-name label with a different color, the existing target label is reused.

For core feature work, check ROADMAP.md first and discuss it in #dev before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See CONTRIBUTING.md.

Model Used

• OpenAI Codex, GPT-5 coding agent with tool use and local command execution.

Checklist

• I have included a thinking path that traces from project context to this change
• I have specified the model used (with version and capability details)
• I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
• I have run tests locally and they pass
• I have added or updated tests where applicable
• If this change affects the UI, I have included before/after screenshots
• I have updated relevant documentation to reflect my changes
• I have considered and documented any risks above
• I will address all Greptile and reviewer comments before requesting merge