[fml] Status keeps its own copy of the message - #194161

fml::Status stores its message as a std::string_view, and its constructor takes one, so passing a std::string compiles without a word and the status points into that string's buffer. CommandQueueVK::Submit does exactly that after a failed Vulkan submit: it builds the status from a local submit_error string inside the fence callback and returns it after the string is gone, so anyone who reads message() reads freed memory. Every other caller passes a literal, which is why it hasn't shown up.

Status::message_ is now a std::string. The constructor still takes a std::string_view and message() still returns one, so no caller changes, and the doc comment says how long that view stays valid. OK statuses have an empty message and don't allocate. I'd rather fix the type than the one caller, because the next caller that formats a message would fall into the same trap.

Where it was verified. macOS arm64, host_debug_unopt_arm64, rebased on current main. The new fml/status_unittests.cc covers a literal message, a runtime message changed or destroyed after the status is built, and a copied status. Without the change two of those fail every time (message() returns secon for second), and the one that reads freed memory fails reliably only under ASan; with it fml_unittests --gtest_filter='StatusTest.*' is 5/5 and the whole of fml_unittests 208/208. Because status.h is included widely I also built impeller_unittests, gpu_unittests, flow_unittests and flutter_tester, and ran the flow_unittests frame timing tests that check status messages (15/15); CI covers the rest of the tree.

Fixes #194151

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.