no-removed-manifest-property: extend to routing.targets[].viewName/viewPath/viewLevel under _version 2.0.0+

[marianfoo]

Is your feature request related to a problem? Please describe.

When migrating a UI5 freestyle app to manifest _version: "2.0.0" (UI5 1.136+),
the routing-target keys viewName / viewPath / viewLevel are deprecated in
favour of name / path / level + an explicit "type": "View". The
@ui5/manifest schema marks them as "deprecated": true with guidance text
pointing to the v2 replacement, and the official Migration Information for
Upgrading the Manifest File doc lists this under the 2.0.0 (1.136) "Deprecated
Manifest Entries" row.

In practice, leaving the v1 keys in a v2 manifest produces a silent failure:
the router matches the route ("The route named 'main' did match"), but no view
is placed in any column of the FCL — the page renders blank. The only
diagnostic signal is a single console warn a millisecond after route match:

page stack is empty but should have been initialized -
application failed to provide a page to display

I expected no-removed-manifest-property to catch this, but on
@ui5/linter@1.19.0 it doesn't:

• The rule's detection scope is limited to resources/js, rootView/async,
  and routing/config/async.
• lib/linter/manifestJson/ManifestLinter.js line 98 does
  const name = target.name ?? target.viewName; — it accepts either form
  silently.
• Running ui5lint against a v2 manifest with viewName / viewPath /
  viewLevel and no type: "View" produces zero manifest-level findings.

Concrete repro — this manifest fragment runs blank but lints clean:

{
    "_version": "2.0.0",
    "sap.ui5": {
        "routing": {
            "config": {
                "routerClass": "sap.f.routing.Router",
                "viewType": "XML",
                "viewPath": "my.app.view"
            },
            "routes": [
                { "pattern": "", "name": "main", "target": ["main", "welcome"],
                  "layout": "TwoColumnsMidExpanded" }
            ],
            "targets": {
                "main":    { "viewName": "Main",    "viewLevel": 1, "controlAggregation": "beginColumnPages" },
                "welcome": { "viewName": "Welcome", "viewLevel": 2, "controlAggregation": "midColumnPages" }
            }
        }
    }
}

Describe the solution you'd like

Extend no-removed-manifest-property (or add a sibling rule) to flag the
following when _version >= 2.0.0:

• sap.ui5.routing.config.viewPath → suggest path + type: "View"
• sap.ui5.routing.targets[].viewName → suggest name + type: "View"
• sap.ui5.routing.targets[].viewPath → suggest path + type: "View"
• sap.ui5.routing.targets[].viewLevel → suggest level + type: "View"
• sap.ui5.routing.targets[].viewId → suggest id + type: "View"

Ideally with an auto-fix that renames the keys and inserts "type": "View" on
each affected target (and on routing.config as a sensible default). The fix
shape mirrors what the SAP Help migration doc already prescribes verbatim.

After-shape for the same example:

"routing": {
    "config": {
        "routerClass": "sap.f.routing.Router",
        "type": "View",
        "viewType": "XML",
        "path": "my.app.view"
    },
    "routes": [
        { "pattern": "", "name": "main", "target": ["main", "welcome"],
          "layout": "TwoColumnsMidExpanded" }
    ],
    "targets": {
        "main":    { "type": "View", "name": "Main",    "level": 1, "controlAggregation": "beginColumnPages" },
        "welcome": { "type": "View", "name": "Welcome", "level": 2, "controlAggregation": "midColumnPages" }
    }
}

Describe alternatives you've considered

• Relying on @ui5/manifest schema's "deprecated": true flag. The schema
  already marks these keys deprecated with the correct migration text, but the
  schema validator (Ajv via @ui5/mcp-server's run_manifest_validation, with
  strict: false) ignores the deprecated flag — a manifest with the legacy
  keys validates as isValid: true. A custom Ajv post-processing pass could
  surface deprecations, but a dedicated linter rule is more discoverable and
  carries the fix.
• Documentation only. The migration is documented, but with no lint signal
  the failure mode is "blank page, no errors" which is hard to attribute. Most
  troubleshooting paths I've seen reach for FCL layout (a different trap)
  before checking the target shape.

Additional context

• Migration source: [Migration Information for Upgrading the Manifest File](https://help.sap.com/docs/SAPUI5/b2f662dd9d7a4ec680056733050b4d34/a110f762148a4933a33d30751a37a743.html?version=1.147) — see the 2.0.0 (1.136) "Deprecated Manifest Entries" row.
• @ui5/manifest@1.86.0 schema already has the canonical "do this instead" text on each property's description, so a rule message can quote that verbatim.
• Tested empirically on UI5 1.147.2 + manifest _version: "2.0.0" + sap.f.routing.Router (the symptom should reproduce on sap.m.routing.Router too — same code path in core, but I haven't verified).

[flovogt]

Thanks a lot for providing the insightful context. We have this enhancement already tracked in the backlog item CPOUI5FOUNDATION-1121. I will update the issue as soon as we have implemented these improvements.

[flovogt]

Regarding manifest v2 and Ui5 linter. For the time being we have agreed on following approach.

1. Keep manifest.json v1 and execute UI5 linter
2. Fix all reported errors in the manifest.json
3. Upgrade manifest.json to v2 and you're good to go

However, I wonder why no no-removed-manifest-property error is logged with message Property 'viewLevel' has been removed in manifest version 2 and must no longer be provided for the legacy view routing properties

[marianfoo]

However, I wonder why no no-removed-manifest-property error is logged with message Property 'viewLevel' has been removed in manifest version 2 and must no longer be provided for the legacy view routing properties

is this a question to me or a question for yourself to answer?

[flovogt]

It is a question and reminder to myself to check this aspect.

[flovogt]

I have checked the scenario and it's valid. These checks are missing and will be implemented with CPOUI5FOUNDATION-1121.