Add supersedes tag and SHOULD-level guidance for product identity changes

[ericfj2140]

Summary

This PR adds a small amount of SHOULD-level guidance around product identity and introduces an optional supersedes tag for versioned product listings.

The intent is to reduce the risk that social data (reviews, etc.) can be "hijacked" by radically changing an existing product while keeping its logical identity, without breaking existing implementations.

Changes

1. Product Listing (Kind: 30402)

   • Add a supersedes optional tag for referencing a previous product listing ("30402::<d>").
   • Add a short "Product identity and mutability" subsection:
     • Treat content, title, summary, and primary image tags as identity-defining fields.
     • Substantial changes to these SHOULD be published as a new product listing with a new d.
     • Operational fields (e.g. price, stock, shipping-related tags) MAY be updated in place without resetting social context.

2. Product Reviews (Kind: 31555)

   • Add a note that when a product listing supersedes another via supersedes, clients MAY display review/rating history from previous versions, but review events SHOULD remain attached to the specific product reference they were created for.

Backwards compatibility

• All new behavior is expressed as SHOULD/MAY.
• No existing tags or kinds are changed.
• Existing clients that ignore supersedes or the new guidance will continue to work unchanged.

[alejandro-runner]

I think this makes sense. The key debate is what makes sense as the identity defining fields:

• Title and summary for sure
• Picture I think should not be included. Losing all the reviews because you got a better picture of the product is iffy
• Content I'm not sure about either.

[ericfj2140]

I think this makes sense. The key debate is what makes sense as the identity defining fields:

• Title and summary for sure
• Picture I think should not be included. Losing all the reviews because you got a better picture of the product is iffy
• Content I'm not sure about either.

Up for discussion of course, but included picture because that seems pretty easy to abuse with a bait and switch. But yeah, it also makes sense someone should be able to update a product photo without changing the product. Pure marketing. And maybe abusive behavior would just affect the reputation of the seller anyway.

Content could be nice to be able to split into core/non-core descriptors. Don't want to be too prescriptive though. I do think some core features about a product changing, like ingredients for example, justify a fresh start with social data. That being said, sorting social data 'by newest' also takes care of a lot of those cases over time.

[ericfj2140]

Updated per discussion: supersedes now uses a full address (30402::) and is explicitly advisory. I removed the prescriptive identity-field list and left product/versioning policy to client implementations.