fix(seed): stop chdir before nested import

[cs-raj]

Summary

• Seed importer: Removes process.chdir(tmpPath) before running the nested cm:stacks:import so process.cwd() stays the directory where the user invoked the CLI.
• Tests: Fixes contentstack-seed failures in interactive.test.ts (Inquirer default export mock) and github/client.test.ts (tar.extract mock typing).

Motivation

While chdir was intended to keep import backups under the temp extract directory, it had two downsides:

1. Logs: The CLI resolves the default log base using getLogPath(), which falls back to cwd/logs. After chdir, that pointed at the OS temp tree instead of the usual CLI working directory (for example cli/packages/contentstack/logs).
2. Backups: Import’s backup handler places default _backup_* folders under process.cwd(). With chdir, those appeared under temp; temp cleanup is not guaranteed, so isolation did not buy much.

Nested import already receives an absolute -d path; changing directory is not required to locate stack content.

Behavior changes

Area	Before	After
Session / file logs (default config)	Often under …/tmp-…/logs/…	Under cwd/logs/… (same as a normal cm:stacks:import from that directory)
Default import backup dir	Next to extract under temp	path.join(cwd, '_backup_<random>') — same as standalone import from that cwd

Test changes

• test/seed/interactive.test.ts: Mock inquirer with { __esModule: true, default: mockInquirer } so import inquirer from 'inquirer' in production code resolves at runtime.
• test/seed/github/client.test.ts: Use (tar.extract as unknown as jest.Mock) when assigning the mock to satisfy TypeScript (TS2352).
• test/seed/importer.test.ts: Assertions that expected chdir were removed when chdir was dropped from importer.ts.

How to verify

cd cli-plugins/packages/contentstack-seed
pnpm test

Run cm:stacks:seed from cli/packages/contentstack (or your usual cwd) and confirm logs appear under ./logs and any _backup_* folders appear under that cwd if import creates a backup.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed