feat: support process-to-process pushes via arweave-scheduler@1.0

[charmful0x]

this PR teaches schedulers to advertise their required codec on 422, and push@1.0 to retry generically with it:

• legacy scheduler@1.0 (ao.TN.1) requires ans104@1.0 -- (ao.N.1 case remains as-is)
• arweave-scheduler@1.0 requires tx@1.0

for tx@1.0, push reuses the target process authority selection, fetches the target-aware L1 price and anchor through arweave@2.9, signs a data-free L1 tx, and posts it through the scheduler

preserves the existing httpsig@1.0 -> ans104@1.0 fallback, from-* provenance, redirects, and security policy. accepted L1 submissions return as pending (202)

live L1 probe:

• 5CVU user -> P1: a0qln7wLeBtVb7y9TaJ7NSDHVSYKsztIkVaqdorppmY
• P1 -> P2, signed by vZY2XY authority: 0zVfrxEbxNTiWS_l-FfiRkewfLHAMdOrxy63yczzCKk
• P2 indexed and computed slot 3
• from-process=P1
• missing scheduler is omitted

[samcamwilliams]

Can we think of a better way to make this generic, I wonder? We shouldn't have devices break their boundaries like this (making the generic push functionality tied to the Arweave libraries).

Ideas:

• What about a generic commit request flag like add-fee: standard | MinimumFeeMultiplier?
• That would work for Arweave, but ideally whatever solution we build will also work if -- for example -- we build a AO-staked committees for scheduling, too, or any other type of scheduler. Perhaps that means that actually what we are missing is a generic 'how much will this cost'-type request?
• I don't know if the [not x]402 schema ever described how this should work, but we should check it out. I think we probably want something like a ~scheduler@1.0 API key that gives us a quote. Alternatively, perhaps HEAD X could generically cover this for us? ~p4@1.0 could answer with the estimate response from the pricing-device if the user adds /schedule as a paid endpoint, but otherwise it could fall through to normal execution and the schedule key in the scheduler implementation could catch it?

All of these seem janky but it is probably worth us spending an hour thinking through the right direction. If we realize it is too complex to do today, then we could fallback to this approach.

[charmful0x]

thanks for the feedback! i thought thoroughly about this, and taking into account Ao-Core architecture, and i went with the explicit scheduler /quote idea: it return a commitment spec, so push stays generic and tx@1.0 handles the Arweave tx with the existing authority-selected wallet. no extra payment layer yet (e.g. p4), and i kept the 422 codec fallback, and live probed the full flow on L1 -- approach proposal: #1125

[samcamwilliams]

Commitment spec is a nice idea! Great thinking.