Maintain two patch files: full-personal and slim-upstream, when shipping a fork PR

When you have a long-running fork of an upstream project where you've been iterating multiple features into one patch for convenient deploy (e.g. main feature + experimental sliders + workarounds), the temptation when submitting upstream is to push the whole bundle and let the maintainer slim it. Better pattern: maintain two patch files in your fork repo — one with everything you actually run in production (deploy from this), one slim subset with only upstream-ready code (push this as the MR). Critical because: upstream maintainers will reject bundled PRs with caveats like 'two of these three slider features have known browser-specific bugs,' but might accept the standalone clean feature. Surgically extract the slim version by applying the full patch on a clean branch off origin/main, then deleting the personal-only hunks with file edits, then git diff > slim.patch. Verify the slim version is materially smaller (in our case 199 LOC vs 443 LOC bundled). For the upstream PR description, also strip any mention of the personal-only features so the reviewer doesn't even know they exist — they'll see a clean focused proposal.