Fix storage file names that contain %, ? or #

An object key in a connected bucket can contain %, ? or #, and until today a storage:// reference to one of those files did not work. 50%.mp4 was refused as a malformed path, clip#1.mp4 and a?b.mp4 were read as a fragment and a query, and a key literally named a%20b.mp4 resolved to a b.mp4.

Those files now work as job inputs and as destinations.

• In the path, write % as %25, ? as %3F and # as %23. storage://media/clip%231.mp4 names clip#1.mp4. Spaces, unicode and {tokens} stay as they are, and the storage id is never escaped.
• The storage browser and the Deliver to picker in the dashboard write those escapes for you, so a picked file always names the same key.
• A path that is not valid escaping is read as written. A hand-typed storage://media/50%.mp4 still names 50%.mp4.
• Destinations decode escapes the same way inputs always have. A folder written as exports%23final now means exports#final, and one that already held an escape like %20 now means a space.

A raw ? or # in a reference is still refused, and the error now says how to escape it. See the storage overview for how references and destinations work, and delivering job outputs to your own bucket for the feature this fixes.