File a thread out of the box it is in, not the list it was found through

[monorkin]

The filing keys refused a thread opened from a bundle, from a contact's threads, or from search results. That is the customer report behind the card, and the customer is right that all three file fine on the web.

@jeremy — this removes the rule you set in #371, so it wants your eye.

The one fact this turns on

HEY serves every posting's box. postings/_object.jbuilder:

json.(posting, :id, :created_at, :updated_at, :observed_at, :active_at, :box_id)

The SDK's generated Posting has carried BoxId all along. mail.Posting was dropping it on the way through, so the TUI had nothing to ask and fell back to asking the list.

That is also what the web reads. Its toolbar is posting.box.kind — off the row, not off the page you came from — which is why the action bar is the same however you arrived.

What was actually wrong

A list can draw rows from several boxes at once: a search, a label, a collection, a contact's threads. So the list's box was the wrong thing to ask. Filing measured "already in Paper Trail" against whatever box happened to sit behind the results, and the fix for that was to refuse those lists outright rather than to ask the row.

Carry BoxID through, take the box from the posting, and the refusals go with it. Only a topic opened by its id has no row and nothing to file.

The same lookup fixes a case nobody reported: filing from a label or collection list, where the source carries no box kind at all, so the already-in guard could never fire.

The row cleanup

A filed row leaves whichever list was drawn over the box list. Nothing re-reads a search's results or a bundle's threads — both are drawn once when they open — so a row left behind stays there offering to file a thread that has already moved.

That is the second commit of #349, which I dropped while rebasing that PR as unreachable. Removing the refusals is what makes it reachable. Credit to @badta5te for writing it.

How I got here

Worth recording, because I had this wrong twice. First I allowed all bundles, which was too broad — a contact's threads span boxes. Then I narrowed it to unseen bundles only and wrote a comment claiming "a posting carries no box of its own to ask instead", which is simply false. @monorkin ran the TUI, showed me the web performing every one of these actions on the exact screen I had just justified refusing, and that sent me to the jbuilder.

Checks

make check passes. The behaviour is mutation-checked: dropping BoxID at the edge fails the new internal/mail test, and removing the row cleanup fails the list tests. The help bar is asserted directly for a bundle, a contact's threads and a search, since the reported symptom was the help bar rather than the keys.