If Alloy has no more arrows of any type she try craft some arrows of type (order asc by enum value)

This is not tested.

When Aloy store looted resources she try put into backpak most rare and valuable things, and stack resources which has already in backpack

These two criteria cannot be met together. There must be a priority; either stacking happens first, or adding new items happen first.

(Actually, there are 3 criteria, since Rarity and Value are different: the tiebreaking between these two fields aren't specified either)

There are no random tests.

Is the BodyComponent.IsRemovable flag even useful? There aren't anywhere for BodyComponent to keep track of the remaining abount of shots for removing (since RequiredShotsForRemoving is get-only).

If BodyRemovableComponent can be added/removed from IMachineAnimal freely, why is IMachineAnimal.Components a IReadOnlyCollection<BodyComponent>?

MachineAnimal's so-called factory pattern of WithFourLegs is not even a proper factory pattern: Factory pattern should only create the object after the config operations. Instead it creates the body components by default and WithFourLegs will replace the entire body components with something else. This is again insane design.

Tests should not use Assert.True and Assert.False: it doesn't show what the original expected and actual values are (all they give is "this flag is not expected").

What happens if Bow.ReloadForAttack is called when there is an ammo already loaded?

Resource is implicitly assumed to be distinguished by Name, but there are nothing in the code that assures this (e.g Equals and GetHashCode are not overridden).

This applies to every other class as well.

This is an issue

Certain operations have success/failure semantics but are no explained, e.g Quiver.AddArrows can fail, but what does it mean by a failure? What happens in this case? Do we not add any arrows, or only add as much as possible?

These cases are never explained, and tests never touch them because they only consists of shallow tests of the simplest scenarios.

The kata's OOP design is horrible: it delegates everything and its testing through Aloy instead of through the individual objects, which makes Aloy the God object for all hunter-related objects. Many things in these objects are not tested, e.g every single method in Quiver is not tested because they're only tested through Aloy's actions.

This is why there are many pointless methods in Aloy that just delegates to the corresponding methods in Backpack/Quiver/etc.

Certain designs in the kata that makes no sense. e.g Why IHunter doesn't have a backpack if it is a core function of a hunter to have backpack to store things? How does one even expect Backpack-related methods on IHunter to work?

These are for some reasons implemented onto instances of IHunter instead, which makes no sense whatsoever. If an IHunter is supposed to have a backpack, then it should have this property in the interface. If it doesn't have one, then Aloy should implement from a separate interface IHasBackpack, IArcher or something that provides said hunter methods of interacting with a backpack.

There are a lot of errors in the initial code, such as

src/Solution.cs(305,23): error CS0508: 'BodyPart.AddComponent(BodyComponent)': return type must be 'void' to match overridden member 'BodyComponent.AddComponent(BodyComponent)'
src/Solution.cs(329,23): error CS0508: 'BodyRemovableComponent.AddComponent(BodyComponent)': return type must be 'void' to match overridden member 'BodyComponent.AddComponent(BodyComponent)'

And some errors from the sample test code:

tests/Fixture.cs(145,27): error CS0103: The name 'GetResources' does not exist in the current context

Required usings in initial code are also missing.

I started working on this but quickly ran into issues.

First off, make sure that "Backpack" is spelled correctly throughout your code (you often use "Backpak instead).

Secondly, it is not specified how Resourcees are distinguished. By their name? Then I'd have to rely on the fact that every Resource object with the same name has the same properties. This kind of design seems error-prone to me.

Overall I think that the kata is perhaps too ambitious in scale. It may be wiser to make it a series (which, judging by the kata name, is what you plan anyway), and just implement a few smaller parts of the interface in this kata, and build in that in future kata.