I think you might be conflating a few different projects that could perhaps be tackled one at a time?
For the component library, check out existing systems like MUI and how they are implemented to be easily usable, styleable, and extensible. The documentation and typing are great, as are the examples. They have a marketplace of sample apps built using those components. Can you create something as useful for your team? This is less about how they are coded behind the scenes and more about their developer experience and ergonomics.
For the design system, do you also have a design and UX background (color, typography, UI, accessibility, etc.?) and a working understanding of how all that is used to come up with a design? Does your team currently use any tools to assist them with design consistency (like a style guide or component library software, or any system for getting tokens and such in and out of Figma and into frontend projects?). Work with your designers on this one and build them an easy to use pipeline, while also talking to the developers to better understand how they could consume these designs in their projects. Also talk to marketers and branding and management and understand their needs, like what should happen when the logo is updated, a design language is overhauled, brand colors and fonts are adjusted, etc. It's not about the code itself but the process it facilitates, like how to push those changes out for gradual uptake across different teams, frontends, frameworks, etc.
Both of those projects sound more like human problems than coding ones. You're building tools for users, optimizing for their needs, not doing leet code or optimizing shadow DOM performance or creating a new state library. You can do a good job with those without needing to know any super complex React internals. It's more just a lot of tedium and thoughtfulness and empathy, like a lot of frontend work. If you want to do a good job on them, I suspect the work will be 80% discussion and design (and more discussion and design and reviews and changes and disagreements and consensus building) and 20% what turns out to be very basic code, because that's all anyone would really want to use and maintain over the long term. Or maybe you'd build a system on top of an existing one, like MUI or Chakra or Ant or such.
Wanting to contribute to React upstream is a different problem altogether. Meta has no shortage of superstar devs internally, and they also have no shortage of people wanting to leave their mark on the Web by way of drive-by contributions. If I were you I'd study their codebase first and see what the issues of the day are and try to make PRs for open problems not too big in scope but not a trivial fix either. It probably won't be easy or someone would've done it already. Alternatively, you could also make a mark by doing a clear writeup on some particular modern issue (like server components and how they work across different frameworks and build setups, or different caching strategies in 2024, or a review of all the tooling, which is an evergreen problem in frontend land).
But don't try to do all of those at once. The styling and UI lib projects don't call for a master React engineer. They call for a detail oriented team player who spends a lot of time understanding the needs and wants of other developers and designers and makes a system they like. It's not an opportunity to show off, but to work together.
The React upstream or ecosystem contribution can be something separate that you do later, by solving a current real problem (either software or education) based on identified needs the community has expressed. I'd argue that too is about solving user needs, not simply proving that you are advanced at React (which is a prerequisite, not the final output).
----------
The above is just my opinion as a nobody frontend dev who has experience working on such systems, to good peer feedback. Nobody once asked how any of it was written or how good at React I am (I'm honestly not). Nobody ever cared. They cared about whether the processes fit their workflows and satisfied managerial needs while being acceptable to other teams and flexible enough to adapt to the future. These things have short life cycles because new hires inevitably want to leave their mark and exercise their creativity anew.
I don't work for a big tech company and I never contributed to upstream React (though did do small PRs for various small ecosystem projects), so feel free to take all this with a grain of salt :)
Just my 2c.