Conflicting requirements between delivered user story and build ready user story

What should be done to make it clear to dev team and test team that Usecase 2 is valid and delivered user story is invalid.

I wouldn't say that the delivered user story was invalid if it satisfied the criteria stated. In fact, delivery of that story led to the realization that the criteria needed to change and thus Usecase 2 came to be.  That is the whole point of incremental delivery and shows the value of feedback received because of doing work.  It is empiricism in action. 

Should BA updated delivered user story cards or in new user story card s/he should update all those cases that invalidates or descopes the feature delivered.

It is the responsibility of the Product Owner to maintain a backlog of information about the changes, additions, deletions for the Product to keep it valuable. This is the opening statement of the Scrum Guide's section that explains the Product Backlog.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

As the first idea was delivered as requested that work is complete.  Any changes to the current product should be documented in the backlog in a way that the Development team can understand the changes needed and the value the changes will deliver. 

I have intentionally avoided bringing up your Definition of Done, your reference to a dev team and test team, or your expectation of a BA because this would become a much longer post.  I am going to suggest that you revisit the Scrum Guide (https://scrumguides.org/) to refresh your understanding of the Scrum framework.  

What should be done to make it clear to dev team and test team that Usecase 2 is valid and delivered user story is invalid.

If you've got separate dev and test teams it's unlikely it ever will be clear. Neither will be accountable for the application of validated learning.

It depends on what is meant by "invalid".

If Use Case 1 didn't represent what the stakeholders had in mind, I would want to understand how there was a disconnect between the Scrum Team and the stakeholders.

If Use Case 1 represented what the stakeholders were thinking originally, but the delivery of that change led to feedback from stakeholders that led to creating Use Case 2, that's the point of iterative and incremental development methodologies. It's better to learn this quickly - after a short iteration - rather than the end of a very long design, development, test, and deployment process.

Personally, I like to look at Product Backlog Items as changes or deltas. If 2 requires that something done in 1 be undone or modified, then the description would somehow reflect this. I don't think that it's generally necessary to go back in time and update PBIs that reflect delivered work. However, I can think of some cases where that could be desired and useful - like most things, it depends on the particular context in which you are working.

what ever implemented in sprint 1 could have been the understanding of the PO, stakeholders users at that point of time. it is good that the same feature has already got feedback from users/stakeholders to modify or enhance. it should not be seen as conflict.

So the change can be handled as a new product backlog item not to reopen the old cards. Modifications will be always there to maximise its value. it doesn't mean what was done in previous iterations were waste of time.

What should be done to make it clear to dev team and test team that Usecase 2 is valid and delivered user story is invalid.

the need of sprinting is to build better products through empiricism.  This basics need to be made clear to the team.

You will keep correcting your art until it comes beautiful. isn't it ?