Two bounded contexts can refer to the same object. But only one controls the lifespan of the object.
The bid belongs directly to the Auction BC. A book that I recommend to many people is Java Modeling in Color with UML it provides a great set of tools to help with domain modeling.
Color-based modeling categorizes domain objects into four archetypes: Person/Place/Thing, Role, Descriptor, and Moment/Interval.
I've gone back and forth about mapping the concepts in the book with DDD concepts. Specifically thinking about a heuristic for determining BCs and Aggregate Roots based on Archetypes.
What I do know is that Membership and Auctions are two separate BCs (in your example). The process of Managing membership has nothing to do with managing auctions (aside from the fact that members create/bid on auctions. Other than that, they're two separate systems
An Auction is an example of a Moment-Interval archetype, it happens over a given period of time (hence it's an Interval). Off of the Auction are several roles: the Auctioneer, the ItemForAuction, and possibly the WinningBidder. These roles are assigned to Person/Place/Thing archetypes.
For example there is a single Party in the system that represents me Mike Brown. Within the system, the Mike Brown entity might have several roles associated with it. One role would be Member (from the Membership BC) another might be Auctioneer (if I decided to put an item for auction) another might be Bidder (if I bid on an auction). The important thing is that no matter which role I play in the system, the data and functionality associated with that role is isolated to it. Think of roles as decorators, or hats that people wear depending on what they're doing.
If I have a hold of the Mike Brown entity. I can ask the entity "What roles do you have" or "Do you have the X role" and the entity should be able to answer. So I can say, Mike Brown give me your Auctioneer role. From the auctioneer role I should have operations like CreateAuction, CancelAuction, ListActiveAuctions, ListCompletedAuctions. In other words the Role is the engine of the system.
Remember I said that the Auction is an example of the Moment-Interval archetype. These represent significant events or periods within your domain. Another concept associated with a Moment-Interval is what's called Successors. For example a Bid is a Successor to an Auction. A bid only exist within the realm of a specific auction (i.e. a Bid is part of the Auction's Aggregate).
If the User or Member who created a bid is removed from the system, that does not negate the fact that a Bid was placed. (No more than Divorcing your wife negates that you had children together, the wife is no longer part of your Family aggregate, but the children very much are...let's ignore the fact that now the children belong to two Family aggregates).
What I am leaning toward as a hypothesis is that For every Moment-Interval, there is a primary Actor that would be the Role archetype. For instance, an Auctioneer is the primary Actor for the Auction M-I. He creates it. The other actors participate in it. I'm leaning toward saying the primary actor for an M-I would be the Aggregate root, except that a single Role entity can participate in multiple M-I.
So the Primary-Actor is a FACTORY for an M-I and controls the lifetime but the M-I itself would be the candidate for an Aggregate root. In this case Auction is an Aggregate root. And it's successors, roles, descriptors, and PPT, are part of its aggregate.
Membership as part of a separate bounded context shouldn't really have direct access to bids, or auctions. Deleting a member for me is actually terminating the Membership M-I (setting an end date on the membership). And any other logic involved in ensuring that the user does not have access. The member still exists, but is inactive. His historical bids are still there. Everyone is happy.