Render what ember-cli-rails reports about a built application

[tricknotes]

Why

The helpers derived a built application's layout for themselves: the assets directory, the index.html that refers to it, the package.json that names it, and whether the build is Vite-based.

ember-cli-rails runs the build and reports all of it.
Deriving it twice meant the two could disagree — the Vite check here looked for a module script in the generated index.html, while ember-cli-rails reads the configuration file at the application's root.

It also meant this gem tracked EmberCli::App closely while never declaring that it needed it, which is why it feature-detected the development server with respond_to?(:dev_server?).

Depends on tricknotes/ember-cli-rails#687, which adds the API this renders and drops the dependency in the other direction.
Bundler refuses to resolve a dependency that points both ways, so that has to land first.

What

Read the application through EmberCli::Embedding from ember-cli-rails instead of deriving it:

• #startup_tags? in place of the local Vite check and the development server feature detection
• #startup_tags(prepend:) in place of extracting the boot tags of a Vite build
• #javascript_assets(prepend:) and #stylesheet_assets(prepend:) in place of the local asset-map lookup

Apart from that, the helpers call only EmberCli[name] and EmberCli::App#build.

prepend goes to those readers rather than being joined on here, because which URLs it applies to is something ember-cli-rails decides: it mounts the build output, so it does not apply to an asset served from a CDN or a font service.

EmberCli::Assets::Paths, Lookup, AssetMap, DirectoryAssetMap and Url are removed, as is EmberCli::Assets::BuildError — a missing or unresolvable asset now raises EmberCli::BuildError.
The helpers are left with the one job they have: turning what ember-cli-rails reports into tags.

The dependency on ember-cli-rails is declared, so the development server no longer needs feature detection, and nokogiri is no longer a direct dependency.

The feature suite now builds a Vite application by default.
It used to build only a classic one and leave the Vite path to a scenario in ember-cli-rails that no longer renders the helpers, so nothing booted a Vite build from them any more.
bin/setup builds the dummy application from the Vite-based blueprint (ember-new-output v7.0.0) by default, and from the last Broccoli-based release with EMBER_BUILD=classic, as CONTRIBUTING.md describes.

CI follows the same default:

• every Ruby and Rails combination runs against the Vite build, including Ruby 4.0 with Rails 7.2, 8.0 and 8.1, on Node 26
• the classic build runs at both ends of the supported range, Ruby 3.2 with Rails 7.0 on Node 20, and Ruby 4.0 with Rails 8.1 on Node 26
• jobs are named after what each version is for, as in build (Ruby 4.0, Rails 8.1), with classic added to the classic ones

Compatibility

EmberCli::Assets::Paths, Lookup, AssetMap, DirectoryAssetMap, Url and EmberCli::Assets::BuildError were public constants.
Anything referencing or rescuing them needs updating; ember-cli-rails documents the replacements in its UPGRADING.md.

CI job names change, so any required status check that names a job has to be updated to the new name.

Open before release

• The dependency on ember-cli-rails names no version yet, because the release that reports a built application is not published.
  Depend on ember-cli-rails 1.x #47 constrains it to the 1.x series; merge it into this branch once ember-cli-rails 1.0.0 is published.
• Until that release exists, the Gemfile resolves ember-cli-rails from the branch of Own the interpretation of an application's build output ember-cli-rails#687 that adds the API, so that CI can run.
  That line comes out at the same time.

Testing

• spec/helpers passes against EmberCli::Embedding
• the feature suite passes against the Vite build in a real browser (7 examples, 0 failures, with spec/helpers and spec/lib)
• CI passes on every job of the matrix above, with Node 26.10.0 installed
• the behaviour that moved — the remote assets of Keep assets hosted outside the build out of the asset lookup #43 and the nested assets of Find the assets nested in the build output #45 — keeps its coverage in ember-cli-rails