v3.33.1: health and duplication baselines in CI, Vitest fixes

Bug fixes

• The GitHub Action and the GitLab template can baseline health and duplication on the default run. A project with existing complexity can now gate the default fallow run with a baseline. Set the health-baseline and dupes-baseline inputs of the action, or FALLOW_HEALTH_BASELINE and FALLOW_DUPES_BASELINE in the GitLab template. Create the files with fallow health --save-baseline and fallow dupes --save-baseline. Other commands ignore these inputs. Both integrations report a stale health or duplication baseline, or one that another command saved. fail-on-stale-baseline (FALLOW_FAIL_ON_STALE_BASELINE) judges these baselines too. It also judges a --health-baseline or --dupes-baseline flag that you pass through args (FALLOW_ARGS). (#3316)
• The action and the GitLab template no longer count health findings that a baseline accepts. With a health baseline, the CLI passed, but the action and the GitLab template failed the job with fail-on-issues. A fallow health run also failed the job. The count now uses the findings that remain after the baseline. (#3316)
• The job summary counts health findings after the baseline. With a loaded health baseline, fallow report --format github-summary shows the new findings and gives the accepted ones as context, for example "2 new functions exceed thresholds (74 in the baseline)". Without a baseline, the summary does not change. (#3316)
• fallow --help names the baseline flags of the bare run. On bare fallow, --baseline and --save-baseline hold the dead-code baseline only. When a bare run gets a fallow health or fallow dupes baseline through --baseline, fallow now prints a note that tells you to use --health-baseline or --dupes-baseline. (#3316)
• The Vitest JSX import source follows the Vitest project model. On Vitest 5, an inline test.projects entry inherits the JSX import source of its config unless it sets extends: false. On Vitest 4, it inherits only with extends: true. Fallow reads the Vitest version from node_modules/vitest, else from the declared range. Project and base include globs add up. Fallow also reads a config that extends names. It reads project configs with a custom name, such as vitest.e2e.config.ts, also when a glob entry names them. Fallow no longer reports these files as unused. (#3318)
• Fallow reads test.exclude for the Vitest JSX import source. When test.exclude or a negated test.include entry removes a test file, Fallow no longer applies the JSX runtime of its project to that file. Without test.exclude, the Vitest default exclude applies. The globs are relative to test.dir, test.root or the Vite root when the config sets one. (#3318)
• react is no longer an unused dependency when Vitest test files use JSX with the default runtime. When a Vitest config sets no JSX import source, Vite imports the react JSX runtime. Fallow now credits react when a test file of that config has JSX and no @jsxImportSource pragma. A TypeScript test file gives no credit when its tsconfig sets jsxImportSource, or a jsx mode without the automatic runtime. The credit applies only to the workspace of the test file. A vite.config.* next to a vitest.config.* gives no credit, because Vitest does not load it. (#3318)
• The source-map warning of fallow coverage upload-source-maps tries the same paths as Fallow Cloud. The CLI dropped the first segments of a source such as webpack:///@scope/app/./src/x.ts, and the cloud did not. The warning could then check a path that the cloud never uses. A shared fixture of path cases now keeps the two implementations equal. (#3320)

Full Changelog: v3.33.0...v3.33.1