Add unsigned ans104 commitments

[JamesPiechota]

Original intent of this PR was to add an unsigned ans104 commitment whenever decoding or committing an ans104 message. I'm not familiar with the context of this change, but it was intended to address an urgent issue that showed up around Nov. 20, 2025. A different workaround for that issue was implemented, removing the urgency, but these changes are still considered the right long-term fix.

State of PR as of Dec. 1, 2025:

• add an unsigned ans104 commitment whenever decoding or committing an ans104 message
• prevent unsigned ids from being returned by the transaction, transactions, id, and ids graphql queries
• fix a bug in dev_codec_ans104:commit (it was returning a #tx rather than message)
• fix a bug in dev_codec_ans104_to:maybe_load (clean out httpsig commitments that were getting added to nested messages)
  • Note: this may be the change that fixes the dev_codec_ans104:unsigned_mixedcase_bundle_map_tags_test failure
• fix a bug in dev_query_arweave where it was return IDs for unmatching commitments (e.g. returning an unsigned ID when the query included an owner filter)

One remaining test failure: hb_store_gateway:remote_hyperbeam_node_ans104_test

• this test caches a message remotely, then restarts the node with a local cache and tries to query the message.
• It now fails because the node is querying the message with its default ID which is an unsigned httpsig and so is no longer returned by graphql
• The PR includes a workaround to have the node query the message using its signed ID. This workaround is not sufficient and should likely be reverted.

Open Questions

Context: Default ID

The root cause of many of the errors hit developing this PR is that several parts of the HyperBEAM codebase implement the concept of a "default ID", but this is not a formalized concept in HB and isn't implemented consistently. In these cases the "default ID" is just an unsigned httpsig ID. Some examples:

• dev_message:id
  • In general dev_message:id only generates IDs for signed commitments, if no signed commitment is found, it defaults to using an unsigned httpsig id
  • This is true even if none or all is passed as the committers value when calling dev_message:id
    • When none is provided, list of commitments is empty and so logic defaults to httpsig id
    • When all is provided, only commitments with a committer tag (i.e. signed commitment) are considered
• hb_cache:write
  • When writing a message to a cache the unsigned httpsig ID is always returned - even for messages without any httpsig commitments or which have another unsigned commitment.

Context: GraphQL

Prior to this PR GraphQL was inconsistent in its ID handling. Querying a message matching on the default ID (i.e. unsigned httpsig id) will cause all IDs (signed IDs as well as default ID) of the matching messages to be added to the match list (and either all returned for transactions or an arbitrary ID to be returned for transaction)

• This happened in match_args when all matching IDs were exploded to all IDs
• This is exacerbated by the hb_message:id logic which excludes unsigned IDs other than the default ID. As a result graphql will only return signed IDs, with the exception of unsigned httpsig IDs which are returned. Unsigned ans104 IDs, for example, will never be returned.

Questions

1. Should we fix the dev_message:id implementation so that it can generate IDs off of unsigned commitments?
   • i.e. specifying all should select unsigned in addition to signed commitments
2. Should we formalize the concept of a Default ID?
   • I.e. every message can always be referenced by its default id regardless of what commitments it has.
   • This would fix some bugs due to inconsistent Default ID handling as well as simplify some logic (e.g. any code path that doesn't specifically care about what commitments are on a message could just use the Default ID). But it could have some negative consequences I'm not aware of (perhaps data bloat now that all messages will have an extra id and unsigned commitment?)
3. What is the intended GraphQL behavior?
   • Do we want to keep that current behavior (described above under "Context: GraphQL")? Or have graphql only return matching IDs? Something else?