fix: normalise Secret.owner to 'app' for ops[testing] output state

[dimaqq]

ops.Model.add_secret() currently sets owner='application', while Scenario’s declared type for Secret.owner is Literal['unit', 'app', None], causing an inconsistency in test (resulting state) output.

This PR implements option 1a: translate 'application' → 'app' in the Scenario backend when constructing the output state, with no public API changes and no changes to the model or hookcmd call path.

• keeps Ops (runtime path) as-is
• preserves Juju-like semantics in hookcmds
• aligns Scenario with its documented 'app' literal

The API stays the same, and most or majority of unit tests don't get broken.
Output state secret owner string could be validated in tests, but so far I didn't find a test like this across GitHub or the charms that we track the source code for.

[dimaqq]

We've got two alternatives here:

opt 1a, as in this PR:

• no change in model
• translate application to app in Scenario backend
• no change in backend calling hookcmd

opt 1b. have Ops use 'app' internally:

• model would call backend.foo('app')
• no change needed in Scenario's backend
• prod backend would translate app -> application before calling hookcmd

[james-garner-canonical]

I don't fully understand the context for this PR.

[tonyandrewmeyer]

Code change looks good to me, but I think we need to have a clearer PR title (particularly, one suitable for the change log) and more information in the PR description, including a link to the issue.

[dimaqq]

James, #2125 is mandatory reading here I'm afraid.
Meanwhile, I'll write up a better summary and title.

[dimaqq]

I've updated the title and descirption. PTAL.

[james-garner-canonical]

Looks good to me, though I guess this should be fix! so it gets called out properly in the next release notes, even if we suspect no one is using it.

[tonyandrewmeyer]

Looks good to me, though I guess this should be fix! so it gets called out properly in the next release notes, even if we suspect no one is using it.

I feel like ! is for cases when the documented behaviour changes. Otherwise, if it's for any breaking change, it seems like almost all bug fixes would need a !. For our two most recent ones, the machine ID was documented as being int typed and that changed to str, but the ctx one not raising UncaughtCharmError was much more borderline, because we don't actually have almost any docs on that behaviour. Arguably, the ! was wrong there, although calling out the change is the right thing to do, I think.

Here, we already documented that the value would be app and the PR fixes things so we do what the documentation says.