Hash outputs upload, webhook attempts start at 1

Two bugs in what happens after a job finishes its work.

• Outputs with long extensions upload. An ffmpeg job that wrote out.sha256 ran to completion and then failed at the upload step, because that step refused any extension longer than five characters. The command parser accepted the same file, so the job was billed before it failed. Both now follow one rule. .sha256, .sha512, .mpegts, .webvtt and .ffmetadata upload, and a connected bucket receives them like any other output.
• Hash, CSV and log outputs open as text. .sha256, .sha512, .md5 and .log are served as text/plain and .csv as text/csv. .mpegts and .webvtt get the same types as .ts and .vtt.
• Attempt counts start at 1. The X-Rendobar-Attempt header on a webhook read 2 on the first delivery, and a delivery to connected storage recorded two attempts when it had made one. Both now count from 1. For storage the same mistake ended a delivery one try early, so a bucket that is briefly unavailable now gets all five tries before the delivery is marked failed.

If your code reads X-Rendobar-Attempt, the first delivery now carries 1. Nothing else about the header changed.

Output files are covered in the ffmpeg job docs, webhook headers in the webhooks guide, and delivery in the storage docs.