State VS Strategy design pattern

Question

I really know that when we have a state-dependent behaviour, we automatically think of state design pattern, especially when it comes to a behaviour that changes according to the state and at the same time this behaviour will change the state.
A VideoPlayer object - for instance - can move from ReadyState to PlayState to PausedState and again to PlayState and finally to TerminatedState at runtime and based on its state behaves differently regarding the UI and the source of stream.
This is a clear and not ambiguis example.
And for Strategy design pattern we have the search example, where we have to decide about the search startegy (The algorithm) based on system material (Memory concerns for example) Yet this is a clear and not ambiguis example.
What if we have for example:
Sample 1:
A Request object that can be sent (The behaviour) to different systems according to its status (The Request class has status property) and can be not sent at all for some statuses, knowing that once sent or not it will not be resent (No change in its status after the sending is done - maybe later for other user interactions but not immediately). So in this case, do we consider it a State Design pattern (just because it depends on the Request status) or Startegy design pattern (Because the state of a particular object is evaluated once at the beginning and will not change) ?
Sample 2:
Searching (the behaviour) for certain objects is done differently based on the connected User Profile (A profile is sharable accross different users of course) The same question in this case. Do we consider it a Strategy, that we need to determine each time we execute the search user interaction or it is a state-dependent behaviour and thus should belong to the connected User object?