Support startapp and start params

[benonymus]

What

A deep link carrying both startapp and start now opens the Mini App and keeps the start payload. If the user dismisses the Mini App launch confirmation, the chat's Start button sends /start <payload> instead of a bare /start.

Why

The parse loop returns on the first of the two parameters it encounters, so only one ever survived. tg://resolve links are rebuilt with startapp ahead of start, so startapp always won and start was discarded — dismissing the launch prompt left the user in the bot chat with the bot unstarted and the payload gone, recoverable only by opening the original link again. For t.me links the raw query order decided instead, so ?start=…&startapp=… took the bot branch and the Mini App never opened.

How

ParsedInternalPeerUrlParameter.appStart carries a botStartPayload, threaded through ChatControllerInitialBotAppStart to presentBotApp. startapp keeps priority regardless of URL order; a new dismissedWithoutConfirmation hook on the launch confirmation puts the payload on the Start button. Referral start payloads are unaffected. If the Mini App can't launch at all — the bot has no web app, or a named app fails to resolve — a link that carries start now falls back to that payload as a bot start rather than opening a plain chat; links without start behave as before.

Drive-by: also clears a stale progress indicator left in the chat title panel when a launch confirmation is dismissed — a pre-existing issue on the same path.

Testing

Use an account that has never started the target bot. Open a link with both parameters, dismiss the launch confirmation, tap Start, and check the raw webhook payload rather than the rendered message.