`can_save_back` is sent by `object.list` but not by `object.publish`

Repo: viewer
Labels: bug, protocol

Summary

The same object is described differently depending on which method delivered it.

Evidence

indra/newview/llpublishedobjectmgr.cpp:

• buildObjectListLLSD (~762) emits it:

  pub["can_save_back"] = info.mCanSaveBackToContents;   // line 784
  

• buildPublishedObjectLLSD (~728), used to build object.publish payloads, emits
  object_id, object_name, object_description, owner_id, region, inventory and
  linked_objects — but never can_save_back.

Impact

A client that learns about an object via object.publish cannot tell whether
viewer.object.save_back_to_contents is available, while a client that learns about the same
object via object.list can. Whether the Save Back action appears depends on which message
happened to arrive first.

Proposed fix

Emit can_save_back from buildPublishedObjectLLSD as well, so both paths describe an object
identically.

Notes

can_save_back is a live capability hint, not a static property: it is true only when the root
prim has a valid LLSelectNode with a non-null mFromTaskID and is not an attachment. Any fix
should preserve that meaning and keep both builders in agreement.