feat(contractor): add contractor self-onboarding profile components

[serikjensen]

Summary

Adds an isAdmin switch to ContractorProfile (admin by default) that, when false, renders dedicated individual and business self-onboarding profile components, selected by the retrieved contractor's type. Mirrors the Employee Profile facade pattern.

• Discriminated props: ContractorProfileProps gains isAdmin. contractorId is optional in admin mode (omitting it creates a contractor) and required at the type level when isAdmin={false}, since the contractor must already exist for its type to be resolved.
• Hook decoupled from selfOnboarding: useContractorDetailsForm + schema no longer key SSN/EIN behavior off the selfOnboarding flag (matching useEmployeeDetailsForm). SSN/EIN are exposed by contractor type only and submitted whenever present.
• Admin form owns the gating: hiding SSN/EIN and relaxing their requiredness when inviting moved into the admin ContractorProfile via the watched-value + state/effect loop (same pattern as Employee's AdminProfile). Net admin behavior is unchanged.
• New internal components: SelfOnboardingContractorProfile (fetches contractor, branches on type), IndividualSelfOnboardingProfile (name + SSN), BusinessSelfOnboardingProfile (business name + EIN). No toggle, fixed required sets, selfOnboarding: true pinned on the payload.
• i18n copy added for the self-onboarding heading/descriptions/continue button.

The two self-onboarding components stay internal; the only public surface change is ContractorProfile gaining isAdmin + conditional contractorId. A follow-up ContractorSelfOnboardingFlow is out of scope.

Test plan

• Hook tests: SSN/EIN exposed by type and submitted when present regardless of selfOnboarding; promotion now enforces them even while self-onboarding
• Schema tests: SSN/EIN no longer excluded by selfOnboarding; requiredness follows optionalFieldsToRequire
• Component tests: admin still hides SSN/EIN + doesn't require them when inviting; isAdmin={false} individual renders name+SSN and submits SSN; business renders businessName+EIN and submits EIN; type-based branch; hasSsn/hasEin waiver
• tsc --noEmit, ESLint, Prettier, full Contractor suite green
• Manually verified the business self-onboarding view in the SDK Dev App against a demo contractor

Business contractor self onboarding

Screen.Recording.2026-06-26.at.9.44.16.AM.mov

Individual contractor self onboarding

Screen.Recording.2026-06-26.at.9.46.32.AM.mov

Individual contractor self onboarding with field validation

Screen.Recording.2026-06-26.at.9.47.35.AM.mov

Made with Cursor

[serikjensen]

@cursoragent please figure out why the CI docs failures are happening and resolve

[cursor]

I've successfully identified and resolved the CI docs-build failures. Here's what I found and fixed:

Root Causes

1. cspell version incompatibility

• The repository was using cspell@10.0.1, which requires Node.js >=22.18.0
• The CI environment (and local development) was running Node 22.14.0
• This caused the npm run docs:lint:spell step to fail with "Unsupported NodeJS version"

2. Stale documentation directory

• A leftover docs/api/Contractor/hooks.md file from a previous docs restructure contained broken links to ../utilities.md (which doesn't exist in that location)
• The actual utilities file is now at docs/reference/utilities.md
• This caused the Docusaurus build to fail with "Markdown link couldn't be resolved"

Changes Made

✅ Downgraded cspell from v10.0.1 to v9.8.0 – v9 supports Node >=20, making it compatible with Node 22.14.0
✅ Removed the stale docs/api/ directory – eliminated the broken link errors

Verification

All docs-build CI steps now pass locally:

• ✓ npm run docs:lint (front matter validation)
• ✓ npm run docs:lint:markdown (markdown linting)
• ✓ npm run docs:lint:spell (spell check)
• ✓ npm run docs:build (Docusaurus build)

Changes have been committed and pushed to feat/contractor-self-onboarding-profile. CI will automatically re-run on the new commit.